- a way to get the network proximity (needed by Pastry, at least) - pull method of source diffusion in graspe-slave - Use a xbt_set for gras_procdata_t->libdata instead of a dict so that the search can be linear. [sorry for the parts in french :] ### ### Very soon ### - tcp->incoming_socks sock specific tcp (buffsize) useless ### ### Soon ### - gras_os_getload - gras_datadesc_import_nws? - meassock Check that messages don't go on meas socks Implement it - Implement gras_datadesc_cpy to speedup things in the simulator For now, we mimick closely the RL when on simulator, which is not needed. (this was easier to do). gras_datadesc_cpy needs to provide the size of the corresponding messages, so that we can report it into the simulator. - a init/exit mecanism for logging appender - more logging appenders - when a send failed because the socket was closed on the other side, try to reopen it seamlessly. Needs exceptions or another way to differentiate between the several system_error. - cache accepted sockets and close the old ones after a while. Depends on the previous item. ### ### A bit later ### - Adaptative timeout - datadesc_set_cste: give the value by default when receiving. It's not transfered anymore, which is good for functions pointer. ============================================================================ * while (1) { fork; exec the child, wait in father } - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb) - virtualize (linux, solaris, SG) & conditions - binary representation: any type, SNWF (Sender Native Wire Format) - modules (log control, manage, token ring, bw) - cleanups, documentation [autoconf] Check the gcc version on powerpc. We disabled -floop-optimize on powerpc, but versions above 3.4.0 should be ok. The ucontext usability test is too light. It returns success on IRIX, but shouldn't since ucontext are broken for us there. [portability layer] Mallocators [Messaging] Message forwarding Message priority Message declarations in a tree manner (such as log channels) [errors] Better split casual errors from programing errors. The first ones should be repported to the user, the second should kill the program (or, yet better, only the msg handler) Allows the use of an error handler depending on the current module (ie, the same philosophy than log4c using GSL's error functions) Rethink the error codes. Source of inspirations are: - comerr (common error reporting from ext2) - libgpg-error [logs] Several appenders; fix the setting stuff to change the appender Hijack message from a given category to another for a while (to mask initializations, and more) Allow each process in simulation to have its own setting [dict] speed up the cursors, for example using the contexts when available fix multi levels dicts [datadesc] Error handling in cbps Regression tests of cbps ********* * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm ********* [simuler le select sur les sockets avec des threads] Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread charge de faire du pool blocant dessus, et des que ce thread se debloque car il commence a lire qqch, il passe la main a un thread de communication charge de faire la lecture. Quand la lecture est finie, le thread de comm passe la main aux threads d'execution (un par couleur). Voici comment faire le coeur du truc [dixit Olivier]: Une liste est utilisee pour stocker ce que le thread de comm a le droit de lire. Elle est protegee par mutex pour eviter les acces concurents. c'est la "liste de lecture" Une semaphore "de lecture" est utilisee pour permettre aux threads servants des sockets de prevenir le thread de comm qu'ils ont qqch pour lui Dans la liste de lecture, on place les messages en cours de creation, et un ptit mutex pour que le thread de comm dise aux threads servants de retourner ecouter la socket car il a fini Chaque couleur a sa file de callback a appeller, proteger par semaphore et un mutex comme pour la file de lecture Init: initialisation de toutes les semaphore a 0 comm: sem_P(semaphore lecture) couleur: sem_P(semaphore de la couleur correspondante) servant: read (1) sur la socket Arrive d'un message servant: 1) le read debloque (c'est la version de gras, utilisee pour multiplexe sur le XML, ou sur les differentes versions de gras/de pilote reseau) 2) Allocation du message vide pour contenir ce qui s'annonce 3) initialisation du mutex du message_instance a 0 (verrouille) 4) placement du message instance dans la file (prise de mutex, placement, lachage de mutex) 5) sem_V(sempahore) 6) mutex_lock sur le mutex_verrouille sleep 7) quand on revient, on rebloque un read(1), et on recommence comm: 1) on se reveille quand la semaphore se libere (etape 6 des servants) 2) prise d'une tache dans la file (protegee par semaphore) 3) lecture de l'instance de message 4) lache le mutex dans l'instance pour liberer le servant 5) pose le message pret dans la file de la couleur correpondant au premier callback de la pile pour ces {messageID x version} et augmente le semaphore correspondant. 6) se rebloque sur le semaphore de lecture et recommence couleur: 1) on se reveille quand quelqu'un a pose qqch dans sa file des messages prets 2) on le retire de la file 3) on acquiere le mutex d'execution de sa couleur (pour les callbacks cameleon) 4) on execute le callback qu'il faut 5) on lache le mutex de sa couleur Si le callback annonce avoir mange le message a) on libere le message (le payload doit avoir ete libere par l'utilisateur) b) on decremente le TTL du callback, et on le vire si c'etait pas un callback infini et qu'il arrive en fin de vie Sinon a) on place le message dans la liste des messages de la couleur du suivant dans la pile des callback 6) On se rendort sur le semaphore de sa couleur et recommence Emission d'un message: A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau thread de comm pour cela. Fermeture d'une socket client: Probleme: faut tuer le thread servant. Solution pour l'instant: fermer la socket depuis ailleurs. Solution si ca marche pas (ou pas partout): Les servants font des selects sur un pool {leur socket x un pipe fait pour} Quand qqch arrive sur le pipe, c'est le signal du suicide. [Inter-arch conversions] Convert in the same buffer when size increase Exchange (on net) structures in one shoot when possible. Port to really exotic platforms (Cray is not IEEE ;) [XML] Do what is written in the paper (multiplex on incoming HTTP) [DataDesc and Parsing macro] Handle typedefs (needs love from DataDesc/) Handle unions with annotate Handle enum Handle long long and long double Forbid "char", allow "signed char" and "unsigned char", or user code won't be portable to ARM, at least. Handle struct/union/enum embeeded within another container (needs modifications in DataDesc, too) Check short a, b; Check short *** Check struct { struct { int a } b; } Factorize code in union/struct field adding [Other] Allow [homogeneous] dico to be sent Make GRAS thread safe by mutexing what needs to be ************ * La suite * ************ GRAS double (ou encore "GRAS too" ou "too GRAS"): - Message prioritization - Visualisation tool to see what happens in the simulator (Paje ?) - Tool to visualize/deploy and manage in RL GRAS (très): - outils mathematiques pour dire des choses sur la validite du protocole