TODO

   1 - a way to get the network proximity (needed by Pastry, at least)
   2
   3 - pull method of source diffusion in graspe-slave
   4
   5 - Use a xbt_set for gras_procdata_t->libdata instead of a dict
   6   so that the search can be linear.
   7
   8 [sorry for the parts in french :]
   9
  10 ###
  11 ### Very soon
  12 ###
  13
  14 - tcp->incoming_socks
  15   sock specific tcp (buffsize) useless
  16
  17 ###
  18 ### Soon
  19 ###
  20
  21 - gras_os_getload
  22
  23 - gras_datadesc_import_nws?
  24
  25 - Implement gras_datadesc_cpy to speedup things in the simulator
  26   For now, we mimick closely the RL when on simulator, which is not needed.
  27   (this was easier to do).
  28   gras_datadesc_cpy needs to provide the size of the corresponding messages, so
  29   that we can report it into the simulator.
  30
  31
  32 - when a send failed because the socket was closed on the other side,
  33   try to reopen it seamlessly. Needs exceptions or another way to
  34   differentiate between the several system_error.
  35 - cache accepted sockets and close the old ones after a while.
  36   Depends on the previous item.
  37
  38
  39 ###
  40 ### A bit later
  41 ###
  42
  43 - timeout the send/recv too
  44 - Adaptative timeout
  45 - datadesc_set_cste: give the value by default when receiving.
  46   It's not transfered anymore, which is good for functions pointer.
  47
  48 ============================================================================
  49
  50 * while (1) { fork; exec the child, wait in father }
  51
  52  - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
  53  - virtualize (linux, solaris, SG) & conditions
  54  - binary representation: any type, SNWF (Sender Native Wire Format)
  55  - modules (log control, manage, token ring, bw)
  56
  57 [autoconf]
  58   Check the gcc version on powerpc. We disabled -floop-optimize on powerpc,
  59     but versions above 3.4.0 should be ok.
  60
  61 [portability layer]
  62   Mallocators
  63
  64 [Messaging]
  65   Message forwarding
  66   Message priority
  67   Message declarations in a tree manner (such as log channels)
  68
  69 [errors]
  70   Better split casual errors from programing errors.
  71     The first ones should be repported to the user, the second should kill
  72     the program (or, yet better, only the msg handler)
  73   Allows the use of an error handler depending on the current module (ie,
  74    the same philosophy than log4c using GSL's error functions)
  75   Rethink the error codes. Source of inspirations are:
  76    - comerr (common error reporting from ext2)
  77    - libgpg-error
  78
  79 [logs]
  80   Several appenders; fix the setting stuff to change the appender
  81   Hijack message from a given category to another for a while (to mask
  82     initializations, and more)
  83   Allow each process in simulation to have its own setting
  84 - a init/exit mecanism for logging appender
  85 - more logging appenders
  86
  87 [dict]
  88   speed up the cursors, for example using the contexts when available
  89   fix multi levels dicts
  90
  91 [datadesc]
  92   Error handling in cbps
  93   Regression tests of cbps
  94
  95 *********
  96 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
  97 *********
  98
  99 [simuler le select sur les sockets avec des threads]
 100   Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
 101     charge de faire du pool blocant dessus, et des que ce thread se debloque
 102     car il commence a lire qqch, il passe la main a un thread de
 103     communication charge de faire la lecture.
 104   Quand la lecture est finie, le thread de comm passe la main aux threads
 105     d'execution (un par couleur).
 106
 107   Voici comment faire le coeur du truc [dixit Olivier]:
 108     Une liste est utilisee pour stocker ce que le thread de comm a le droit
 109       de lire. Elle est protegee par mutex pour eviter les acces concurents.
 110       c'est la "liste de lecture"
 111     Une semaphore "de lecture" est utilisee pour permettre aux threads
 112       servants des sockets de prevenir le thread de comm qu'ils ont qqch
 113       pour lui
 114     Dans la liste de lecture, on place les messages en cours de creation, et
 115       un ptit mutex pour que le thread de comm dise aux threads servants de
 116       retourner ecouter la socket car il a fini
 117     Chaque couleur a sa file de callback a appeller, proteger par semaphore
 118       et un mutex comme pour la file de lecture
 119
 120     Init:
 121      initialisation de toutes les semaphore a 0
 122      comm: sem_P(semaphore lecture)
 123      couleur: sem_P(semaphore de la couleur correspondante)
 124      servant: read (1) sur la socket
 125
 126     Arrive d'un message
 127      servant:
 128      1) le read debloque (c'est la version de gras, utilisee pour multiplexe
 129         sur le XML, ou sur les differentes versions de gras/de pilote reseau)
 130      2) Allocation du message vide pour contenir ce qui s'annonce
 131      3) initialisation du mutex du message_instance a 0 (verrouille)
 132      4) placement du message instance dans la file (prise de mutex,
 133         placement, lachage de mutex)
 134      5) sem_V(sempahore)
 135      6) mutex_lock sur le mutex_verrouille
 136      sleep
 137      7) quand on revient, on rebloque un read(1), et on recommence
 138
 139      comm:
 140      1) on se reveille quand la semaphore se libere (etape 6 des servants)
 141      2) prise d'une tache dans la file (protegee par semaphore)
 142      3) lecture de l'instance de message
 143      4) lache le mutex dans l'instance pour liberer le servant
 144      5) pose le message pret dans la file de la couleur correpondant au
 145         premier callback de la pile pour ces {messageID x version} et
 146         augmente le semaphore correspondant.
 147      6) se rebloque sur le semaphore de lecture et recommence
 148
 149      couleur:
 150      1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
 151         prets
 152      2) on le retire de la file
 153      3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
 154         cameleon)
 155      4) on execute le callback qu'il faut
 156      5) on lache le mutex de sa couleur
 157      Si le callback annonce avoir mange le message
 158        a) on libere le message (le payload doit avoir ete libere par
 159           l'utilisateur)
 160        b) on decremente le TTL du callback, et on le vire si c'etait pas un
 161           callback infini et qu'il arrive en fin de vie
 162      Sinon
 163        a) on place le message dans la liste des messages de la couleur du
 164           suivant dans la pile des callback
 165      6) On se rendort sur le semaphore de sa couleur et recommence
 166
 167     Emission d'un message:
 168      A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
 169       thread de comm pour cela.
 170
 171     Fermeture d'une socket client:
 172      Probleme: faut tuer le thread servant.
 173      Solution pour l'instant: fermer la socket depuis ailleurs.
 174      Solution si ca marche pas (ou pas partout): Les servants font des
 175       selects sur un pool {leur socket x un pipe fait pour}
 176       Quand qqch arrive sur le pipe, c'est le signal du suicide.
 177
 178 [Inter-arch conversions]
 179  Convert in the same buffer when size increase
 180  Exchange (on net) structures in one shoot when possible.
 181  Port to really exotic platforms (Cray is not IEEE ;)
 182
 183 [XML]
 184  Do what is written in the paper (multiplex on incoming HTTP)
 185
 186 [DataDesc and Parsing macro]
 187  Handle typedefs (needs love from DataDesc/)
 188  Handle unions with annotate
 189  Handle enum
 190  Handle long long and long double
 191  Forbid "char", allow "signed char" and "unsigned char", or user code won't be
 192    portable to ARM, at least.
 193  Handle struct/union/enum embeeded within another container
 194    (needs modifications in DataDesc, too)
 195
 196  Check short a, b;
 197  Check short ***
 198  Check struct { struct { int a } b; }
 199
 200  Factorize code in union/struct field adding
 201
 202 [Other]
 203  Allow [homogeneous] dico to be sent
 204  Make GRAS thread safe by mutexing what needs to be
 205
 206
 207 ************
 208 * La suite *
 209 ************
 210 GRAS double (ou encore "GRAS too" ou "too GRAS"):
 211  - Message prioritization
 212  - Visualisation tool to see what happens in the simulator (Paje ?)
 213  - Tool to visualize/deploy and manage in RL
 214
 215 GRAS (très):
 216  - outils mathematiques pour dire des choses sur la validite du protocole
 217