Logo AND Algorithmique Numérique Distribuée

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