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 - rawsock
  26   Check that messages don't go on raw socks
  27   Rename to meassock or whatever to show that they're not intended for
  28   out of band communication, but for socket operation measurements.
  29
  30 - Implement gras_datadesc_cpy to speedup things in the simulator
  31   For now, we mimick closely the RL when on simulator, which is not needed.
  32   (this was easier to do).
  33   gras_datadesc_cpy needs to provide the size of the corresponding messages, so
  34   that we can report it into the simulator.
  35
  36 ###
  37 ### A bit later
  38 ###
  39
  40 - Adaptative timeout
  41 - datadesc_set_cste: give the value by default when receiving.
  42   It's not transfered anymore, which is good for functions pointer.
  43
  44 ============================================================================
  45
  46 * while (1) { fork; exec the child, wait in father }
  47
  48  - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
  49  - virtualize (linux, solaris, SG) & conditions
  50  - binary representation: any type, SNWF (Sender Native Wire Format)
  51  - modules (log control, manage, token ring, bw)
  52  - cleanups, documentation
  53
  54 [autoconf]
  55   Check the gcc version on powerpc. We disabled -floop-optimize on powerpc,
  56     but versions above 3.4.0 should be ok.
  57   The ucontext usability test is too light. It returns success on IRIX, but
  58     shouldn't since ucontext are broken for us there.
  59
  60 [portability layer]
  61   Mallocators
  62
  63 [Messaging]
  64   Message forwarding
  65   Message priority
  66   Message declarations in a tree manner (such as log channels)
  67
  68 [errors]
  69   Better split casual errors from programing errors.
  70     The first ones should be repported to the user, the second should kill
  71     the program (or, yet better, only the msg handler)
  72   Allows the use of an error handler depending on the current module (ie,
  73    the same philosophy than log4c using GSL's error functions)
  74   Rethink the error codes. Source of inspirations are:
  75    - comerr (common error reporting from ext2)
  76    - libgpg-error
  77
  78 [logs]
  79   Several appenders; fix the setting stuff to change the appender
  80   Hijack message from a given category to another for a while (to mask
  81     initializations, and more)
  82   Allow each process in simulation to have its own setting
  83
  84 [dict]
  85   speed up the cursors, for example using the contexts when available
  86   fix multi levels dicts
  87
  88 [datadesc]
  89   Error handling in cbps
  90   Regression tests of cbps
  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 [Inter-arch conversions]
 176  Convert in the same buffer when size increase
 177  Exchange (on net) structures in one shoot when possible.
 178  Port to really exotic platforms (Cray is not IEEE ;)
 179
 180 [XML]
 181  Do what is written in the paper (multiplex on incoming HTTP)
 182
 183 [DataDesc and Parsing macro]
 184  Handle typedefs (needs love from DataDesc/)
 185  Handle unions with annotate
 186  Handle enum
 187  Handle long long and long double
 188  Forbid "char", allow "signed char" and "unsigned char", or user code won't be
 189    portable to ARM, at least.
 190  Handle struct/union/enum embeeded within another container
 191    (needs modifications in DataDesc, too)
 192
 193  Check short a, b;
 194  Check short ***
 195  Check struct { struct { int a } b; }
 196
 197  Factorize code in union/struct field adding
 198
 199 [Other]
 200  Allow [homogeneous] dico to be sent
 201  Make GRAS thread safe by mutexing what needs to be
 202
 203
 204 ************
 205 * La suite *
 206 ************
 207 GRAS double (ou encore "GRAS too" ou "too GRAS"):
 208  - Message prioritization
 209  - Visualisation tool to see what happens in the simulator (Paje ?)
 210  - Tool to visualize/deploy and manage in RL
 211
 212 GRAS (très):
 213  - outils mathematiques pour dire des choses sur la validite du protocole
 214