1 * Use of data on the stack as argument to MsgNew does not work
2 * Warn when using a server socket to write, or a client one to poll
4 * while (1) { fork; exec the child, wait in father }
8 Check in autoconf that no datatype is bigger than 64, or dynar_map will
12 Make a script to test how the padding bytes are on the current arch, and
13 constitute a bestiary.
14 Use Arnaud's structure parser in a macro
15 Dynar of type, such as ref of type
16 Generate convertors in assembler ?
22 Messages in a tree manner
25 Interface: open_server, open_client, read, write, flush, close
26 Implementations: TCP, SG (more after my PhD).
29 Better split casual errors from programing errors.
30 The first ones should be repported to the user, the second should kill
31 the program (or, yet better, only the msg handler)
32 Allows the use of an error handler depending on the current module (ie,
33 the same philosophy than log4c using GSL's error functions)
34 Rethink the error codes. Source of inspirations are:
35 - comerr (common error reporting from ext2)
39 Parse argv (check leonie and tbx_arg_iterator in tbx_parameter.h)
40 Several appenders; fix the setting stuff to change the appender
41 Hijack message from a given category to another for a while (to mask
45 Make a real container for the dict, so that the free function may be given
46 only once for the whole tree (would help to send dicts).
48 speed up the cursors, for example using the contexts when available
49 fix multi levels dicts
52 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
55 un peu comme les type_bag RL, mais sans tenir compte d'incoming ni
57 La finesse est de simuler la taille des envois sans les faire
58 On peut aussi imaginer une version faisant ces envois effectivement, qui
59 serait un peu plus lente, mais permettant de debugger cette partie de
62 [pilotes reseaux de sous grassouillet]
63 TCP: utilise le fd. rien a faire.
64 SG: Le send fait le boulot de malloc du recv de fd, et les rempli comme le
66 BLOC: Un nouveau truc, qui envoi des trames les unes derriere les autres,
67 un write copie dans un buffer qui, quand il est plein, part sur la socket
68 avec sa taille devant, et son CRC derriere.
69 C'est le prix a payer pour ne plus mourrir si vite en cas de transmission
70 pourrie (mais ca resoud tjs pas le pb du code malicieux)
71 Possibilite de compresser les buffers avant l'envoi..
73 [simuler le select sur les sockets avec des threads]
74 Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
75 charge de faire du pool blocant dessus, et des que ce thread se debloque
76 car il commence a lire qqch, il passe la main a un thread de
77 communication charge de faire la lecture.
78 Quand la lecture est finie, le thread de comm passe la main aux threads
79 d'execution (un par couleur).
81 Voici comment faire le coeur du truc [dixit Olivier]:
82 Une liste est utilisee pour stocker ce que le thread de comm a le droit
83 de lire. Elle est protegee par mutex pour eviter les acces concurents.
84 c'est la "liste de lecture"
85 Une semaphore "de lecture" est utilisee pour permettre aux threads
86 servants des sockets de prevenir le thread de comm qu'ils ont qqch
88 Dans la liste de lecture, on place les messages en cours de creation, et
89 un ptit mutex pour que le thread de comm dise aux threads servants de
90 retourner ecouter la socket car il a fini
91 Chaque couleur a sa file de callback a appeller, proteger par semaphore
92 et un mutex comme pour la file de lecture
95 initialisation de toutes les semaphore a 0
96 comm: sem_P(semaphore lecture)
97 couleur: sem_P(semaphore de la couleur correspondante)
98 servant: read (1) sur la socket
102 1) le read debloque (c'est la version de gras, utilisee pour multiplexe
103 sur le XML, ou sur les differentes versions de gras/de pilote reseau)
104 2) Allocation du message vide pour contenir ce qui s'annonce
105 3) initialisation du mutex du message_instance a 0 (verrouille)
106 4) placement du message instance dans la file (prise de mutex,
107 placement, lachage de mutex)
109 6) mutex_lock sur le mutex_verrouille
111 7) quand on revient, on rebloque un read(1), et on recommence
114 1) on se reveille quand la semaphore se libere (etape 6 des servants)
115 2) prise d'une tache dans la file (protegee par semaphore)
116 3) lecture de l'instance de message
117 4) lache le mutex dans l'instance pour liberer le servant
118 5) pose le message pret dans la file de la couleur correpondant au
119 premier callback de la pile pour ces {messageID x version} et
120 augmente le semaphore correspondant.
121 6) se rebloque sur le semaphore de lecture et recommence
124 1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
126 2) on le retire de la file
127 3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
129 4) on execute le callback qu'il faut
130 5) on lache le mutex de sa couleur
131 Si le callback annonce avoir mange le message
132 a) on libere le message (le payload doit avoir ete libere par
134 b) on decremente le TTL du callback, et on le vire si c'etait pas un
135 callback infini et qu'il arrive en fin de vie
137 a) on place le message dans la liste des messages de la couleur du
138 suivant dans la pile des callback
139 6) On se rendort sur le semaphore de sa couleur et recommence
141 Emission d'un message:
142 A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
143 thread de comm pour cela.
145 Fermeture d'une socket client:
146 Probleme: faut tuer le thread servant.
147 Solution pour l'instant: fermer la socket depuis ailleurs.
148 Solution si ca marche pas (ou pas partout): Les servants font des
149 selects sur un pool {leur socket x un pipe fait pour}
150 Quand qqch arrive sur le pipe, c'est le signal du suicide.
152 [Conversions inter-architectures]
153 Marquer les padding bytes explicitement aux structures (juste le sizeof
155 Marquer les offsetof des fields explicitement a l'ajout.
156 Prevoir tous les encoding pour les types elementaires
157 [taille, sexe, signess[non, a un, a deux]]
158 plus les flotants, justifiant un traitement a part
159 Tester avec autoconf les encodings sur l'archi courante
160 Trouver un moyen de convertir un encoding en un autre (si possible par
162 Generer ces convertors en assembleur a chaud, puisqu'on a rien de mieux a
163 foutre de notre temps
166 Tout comme c'est dit dans les articles
169 Gerer les typedefs (necessite de l'aide de grassouillet)
171 Faut des annotations pour dire si c'est :
173 - un tableau dont la longueur est ailleurs dans la struct
175 Ca peut se faire soit avec des commentaires, soit avec des macros se
176 reecrivant a rien dans la vraie vie, et parsee. Mais le risque est que
177 ces macros soient reecrites avant d'etre passee a mon bordel, selon les
179 Gerer les unions => specifier des annotations, mais j'y crois pas
182 Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
184 Verifier que "char"="signed char" sur toutes les archis
186 Renomer gs_parse_tok_num en gs_parse_token
189 Check struct { struct { int a } b; }
192 Gerer les typedefs pour aliaser un type sur un autre
193 Merger gs_type_union_append_field et gs_type_struc_append_field si possible.
195 gs_type_copy/gs_type_free
196 A quoi sert le champ name de gs_type_struct_append_field ?
197 Ca plante bizarement si on met une structure n'existant pas dans le
199 gs_type_dump, nardin, comment voir ce qui se passe sinon ??
202 Simplifier l'API pour virer les sequences
203 Faire le parseur automatique de structures
204 Faire toutes les modifs aux Utils listees plus haut
205 Simplifier l'envoi de dynar et dico
206 Mettre les mutex et semaphores dans les dynar directement
207 Tenter (politiquement) le passage a GPL, pour voler du code.
213 GRAS double (ou encore "GRAS too" ou "too GRAS"):
214 - Priorite des messages
215 - Outils de visu pour ce qui se passe dans le simulo
216 - Outils de visu/deployement/management pour RL
219 - outils mathematiques pour dire des choses sur la validite du protocole