1 - pull method of source diffusion in graspe-slave
3 - Use a xbt_set for gras_procdata_t->libdata instead of a dict
4 so that the search can be linear.
6 [sorry for the parts in french :]
13 sock specific tcp (buffsize) inutile
21 - gras_datadesc_import_nws?
24 Check that messages don't go on raw socks
25 Rename to meassock or whatever to show that they're not intended for
26 out of band communication, but for socket operation measurements.
28 - Implement gras_datadesc_cpy to speedup things in the simulator
29 For now, we mimick closely the RL when on simulator, which is not needed.
30 (this was easier to do).
31 gras_datadesc_cpy needs to provide the size of the corresponding messages, so
32 that we can report it into the simulator.
34 - callback on reception ?? (to put functions pointer back in place, etc)
36 - category "ignored" should be dropped, since it's not portable (what's its
37 size on remote site?). But function's pointer may benefit from it.
38 We could change it to an attribute just as the "cycle" one. That way, it
39 would get malloced, but not transfered.
46 - datadesc_set_cste: give the value by default when receiving.
47 It's not transfered anymore, which is good for functions pointer.
49 ============================================================================
51 * while (1) { fork; exec the child, wait in father }
53 - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
54 - virtualize (linux, solaris, SG) & conditions
55 - binary representation: any type, SNWF (Sender Native Wire Format)
56 - modules (log control, manage, token ring, bw)
57 - cleanups, documentation
60 Check in autoconf that no datatype is bigger than 64, or dynar_map will
62 Check the gcc version on powerpc. We disabled -floop-optimize on powerpc,
63 but versions above 3.4.0 should be ok.
64 The ucontext usability test is too light. It returns success on IRIX, but
65 shouldn't since ucontext are broken for us there.
68 Dynar of type, such as ref of type
74 Message declarations in a tree manner (such as log channels)
77 Better split casual errors from programing errors.
78 The first ones should be repported to the user, the second should kill
79 the program (or, yet better, only the msg handler)
80 Allows the use of an error handler depending on the current module (ie,
81 the same philosophy than log4c using GSL's error functions)
82 Rethink the error codes. Source of inspirations are:
83 - comerr (common error reporting from ext2)
87 Several appenders; fix the setting stuff to change the appender
88 Hijack message from a given category to another for a while (to mask
89 initializations, and more)
90 Allow each process in simulation to have its own setting
93 speed up the cursors, for example using the contexts when available
94 fix multi levels dicts
97 Error handling in cbps
98 Regression tests of cbps
101 use logging, not printf
104 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
107 [simuler le select sur les sockets avec des threads]
108 Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
109 charge de faire du pool blocant dessus, et des que ce thread se debloque
110 car il commence a lire qqch, il passe la main a un thread de
111 communication charge de faire la lecture.
112 Quand la lecture est finie, le thread de comm passe la main aux threads
113 d'execution (un par couleur).
115 Voici comment faire le coeur du truc [dixit Olivier]:
116 Une liste est utilisee pour stocker ce que le thread de comm a le droit
117 de lire. Elle est protegee par mutex pour eviter les acces concurents.
118 c'est la "liste de lecture"
119 Une semaphore "de lecture" est utilisee pour permettre aux threads
120 servants des sockets de prevenir le thread de comm qu'ils ont qqch
122 Dans la liste de lecture, on place les messages en cours de creation, et
123 un ptit mutex pour que le thread de comm dise aux threads servants de
124 retourner ecouter la socket car il a fini
125 Chaque couleur a sa file de callback a appeller, proteger par semaphore
126 et un mutex comme pour la file de lecture
129 initialisation de toutes les semaphore a 0
130 comm: sem_P(semaphore lecture)
131 couleur: sem_P(semaphore de la couleur correspondante)
132 servant: read (1) sur la socket
136 1) le read debloque (c'est la version de gras, utilisee pour multiplexe
137 sur le XML, ou sur les differentes versions de gras/de pilote reseau)
138 2) Allocation du message vide pour contenir ce qui s'annonce
139 3) initialisation du mutex du message_instance a 0 (verrouille)
140 4) placement du message instance dans la file (prise de mutex,
141 placement, lachage de mutex)
143 6) mutex_lock sur le mutex_verrouille
145 7) quand on revient, on rebloque un read(1), et on recommence
148 1) on se reveille quand la semaphore se libere (etape 6 des servants)
149 2) prise d'une tache dans la file (protegee par semaphore)
150 3) lecture de l'instance de message
151 4) lache le mutex dans l'instance pour liberer le servant
152 5) pose le message pret dans la file de la couleur correpondant au
153 premier callback de la pile pour ces {messageID x version} et
154 augmente le semaphore correspondant.
155 6) se rebloque sur le semaphore de lecture et recommence
158 1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
160 2) on le retire de la file
161 3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
163 4) on execute le callback qu'il faut
164 5) on lache le mutex de sa couleur
165 Si le callback annonce avoir mange le message
166 a) on libere le message (le payload doit avoir ete libere par
168 b) on decremente le TTL du callback, et on le vire si c'etait pas un
169 callback infini et qu'il arrive en fin de vie
171 a) on place le message dans la liste des messages de la couleur du
172 suivant dans la pile des callback
173 6) On se rendort sur le semaphore de sa couleur et recommence
175 Emission d'un message:
176 A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
177 thread de comm pour cela.
179 Fermeture d'une socket client:
180 Probleme: faut tuer le thread servant.
181 Solution pour l'instant: fermer la socket depuis ailleurs.
182 Solution si ca marche pas (ou pas partout): Les servants font des
183 selects sur un pool {leur socket x un pipe fait pour}
184 Quand qqch arrive sur le pipe, c'est le signal du suicide.
186 [Inter-arch conversions]
187 Convert in the same buffer when size increase
188 Exchange (on net) structures in one shoot when possible.
189 Port to really exotic platforms (Cray is not IEEE ;)
192 Do what is written in the paper (multiplex on incoming HTTP)
194 [DataDesc and Parsing macro]
195 Handle typedefs (needs love from DataDesc/)
196 Handle unions with annotate
198 Handle long long and long double
199 Forbid "char", allow "signed char" and "unsigned char", or user code won't be
200 portable to ARM, at least.
201 Handle struct/union/enum embeeded within another container
202 (needs modifications in DataDesc, too)
206 Check struct { struct { int a } b; }
208 Factorise code in union/struct field adding
211 Allow [homogeneous] dynar and dico to be sent
212 Make GRAS thread safe by mutexing what needs to be
218 GRAS double (ou encore "GRAS too" ou "too GRAS"):
219 - Message prioritization
220 - Visualisation tool to see what happens in the simulator (Paje ?)
221 - Tool to visualize/deploy and manage in RL
224 - outils mathematiques pour dire des choses sur la validite du protocole