1 - Use a xbt_set for gras_procdata_t->libdata instead of a dict
2 so that the search can be linear.
4 [sorry for the parts in french :]
11 sock specific tcp (buffsize) inutile
19 - gras_datadesc_import_nws
22 Verifier que les messages vont pas sur des sock raw
24 - gras_datadesc_cpy -> donne la taille prise pour donner un poids aux messages
26 - callback en reception ?? (remettre les pointeurs sur fonction etc)
29 gras_ddt_new_ignored : Pas portable (taille) => virer cat?
30 Necessaire aux pointeurs sur fonction? Renomer 'void'
37 - datadesc_set_cste: Donne la valeur par defaut en reception
38 plus de transfert, ce qui est utile pour les pointeurs sur fct
40 ============================================================================
42 * while (1) { fork; exec the child, wait in father }
44 - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
45 - virtualize (linux, solaris, SG) & conditions
46 - binary representation: any type, SNWF (Sender Native Wire Format)
47 - modules (log control, manage, token ring, bw)
48 - cleanups, documentation
51 Check in autoconf that no datatype is bigger than 64, or dynar_map will
55 Dynar of type, such as ref of type
61 Message declarations in a tree manner
64 Better split casual errors from programing errors.
65 The first ones should be repported to the user, the second should kill
66 the program (or, yet better, only the msg handler)
67 Allows the use of an error handler depending on the current module (ie,
68 the same philosophy than log4c using GSL's error functions)
69 Rethink the error codes. Source of inspirations are:
70 - comerr (common error reporting from ext2)
74 Several appenders; fix the setting stuff to change the appender
75 Hijack message from a given category to another for a while (to mask
76 initializations, and more)
77 Allow each process in simulation to have its own setting
80 speed up the cursors, for example using the contexts when available
81 fix multi levels dicts
84 Error handling in cbps
85 Regression tests of cbps
88 use logging, not printf
91 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
94 [simuler le select sur les sockets avec des threads]
95 Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
96 charge de faire du pool blocant dessus, et des que ce thread se debloque
97 car il commence a lire qqch, il passe la main a un thread de
98 communication charge de faire la lecture.
99 Quand la lecture est finie, le thread de comm passe la main aux threads
100 d'execution (un par couleur).
102 Voici comment faire le coeur du truc [dixit Olivier]:
103 Une liste est utilisee pour stocker ce que le thread de comm a le droit
104 de lire. Elle est protegee par mutex pour eviter les acces concurents.
105 c'est la "liste de lecture"
106 Une semaphore "de lecture" est utilisee pour permettre aux threads
107 servants des sockets de prevenir le thread de comm qu'ils ont qqch
109 Dans la liste de lecture, on place les messages en cours de creation, et
110 un ptit mutex pour que le thread de comm dise aux threads servants de
111 retourner ecouter la socket car il a fini
112 Chaque couleur a sa file de callback a appeller, proteger par semaphore
113 et un mutex comme pour la file de lecture
116 initialisation de toutes les semaphore a 0
117 comm: sem_P(semaphore lecture)
118 couleur: sem_P(semaphore de la couleur correspondante)
119 servant: read (1) sur la socket
123 1) le read debloque (c'est la version de gras, utilisee pour multiplexe
124 sur le XML, ou sur les differentes versions de gras/de pilote reseau)
125 2) Allocation du message vide pour contenir ce qui s'annonce
126 3) initialisation du mutex du message_instance a 0 (verrouille)
127 4) placement du message instance dans la file (prise de mutex,
128 placement, lachage de mutex)
130 6) mutex_lock sur le mutex_verrouille
132 7) quand on revient, on rebloque un read(1), et on recommence
135 1) on se reveille quand la semaphore se libere (etape 6 des servants)
136 2) prise d'une tache dans la file (protegee par semaphore)
137 3) lecture de l'instance de message
138 4) lache le mutex dans l'instance pour liberer le servant
139 5) pose le message pret dans la file de la couleur correpondant au
140 premier callback de la pile pour ces {messageID x version} et
141 augmente le semaphore correspondant.
142 6) se rebloque sur le semaphore de lecture et recommence
145 1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
147 2) on le retire de la file
148 3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
150 4) on execute le callback qu'il faut
151 5) on lache le mutex de sa couleur
152 Si le callback annonce avoir mange le message
153 a) on libere le message (le payload doit avoir ete libere par
155 b) on decremente le TTL du callback, et on le vire si c'etait pas un
156 callback infini et qu'il arrive en fin de vie
158 a) on place le message dans la liste des messages de la couleur du
159 suivant dans la pile des callback
160 6) On se rendort sur le semaphore de sa couleur et recommence
162 Emission d'un message:
163 A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
164 thread de comm pour cela.
166 Fermeture d'une socket client:
167 Probleme: faut tuer le thread servant.
168 Solution pour l'instant: fermer la socket depuis ailleurs.
169 Solution si ca marche pas (ou pas partout): Les servants font des
170 selects sur un pool {leur socket x un pipe fait pour}
171 Quand qqch arrive sur le pipe, c'est le signal du suicide.
173 [Conversions inter-architectures]
174 Convert in the same buffer when size increase
175 Exchange structures in one shoot.
176 Port to really exotic platforms (Cray is not IEEE ;)
179 Do what is written in the paper
182 Gerer les typedefs (necessite de l'aide de grassouillet)
183 Gerer les unions => specifier des annotations
186 Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
188 Verifier que "char"="signed char" sur toutes les archis
190 Renomer gs_parse_tok_num en gs_parse_token
193 Check struct { struct { int a } b; }
196 Gerer les typedefs pour aliaser un type sur un autre
197 Merger gs_type_union_append_field et gs_type_struc_append_field si possible.
200 Faire toutes les modifs aux Utils listees plus haut
201 Simplifier l'envoi de dynar et dico
202 Mettre les mutex et semaphores dans les dynar directement
208 GRAS double (ou encore "GRAS too" ou "too GRAS"):
209 - Priorite des messages
210 - Outils de visu pour ce qui se passe dans le simulo
211 - Outils de visu/deployement/management pour RL
214 - outils mathematiques pour dire des choses sur la validite du protocole