TODO

   1 - Use a xbt_set for gras_procdata_t->libdata instead of a dict
   2   so that the search can be linear.
   3
   4 [sorry for the parts in french :]
   5
   6 ###
   7 ### Avant 0.5
   8 ###
   9
  10 - tcp->incoming_socks
  11   sock specific tcp (buffsize) inutile
  12
  13 ###
  14 ### Avant 1.0
  15 ###
  16
  17 - gras_os_getload
  18
  19 - gras_datadesc_import_nws
  20
  21 - rawsock
  22   Verifier que les messages vont pas sur des sock raw
  23
  24 - gras_datadesc_cpy -> donne la taille prise pour donner un poids aux messages
  25
  26 - callback en reception ?? (remettre les pointeurs sur fonction etc)
  27
  28 - Virer cat ignored
  29   gras_ddt_new_ignored : Pas portable (taille) => virer cat?
  30   Necessaire aux pointeurs sur fonction? Renomer 'void'
  31
  32 ###
  33 ### Apres
  34 ###
  35
  36 - Adaptative timeout
  37 - datadesc_set_cste: Donne la valeur par defaut en reception
  38   plus de transfert, ce qui est utile pour les pointeurs sur fct
  39
  40 ============================================================================
  41
  42 * while (1) { fork; exec the child, wait in father }
  43
  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
  49
  50 [autoconf]
  51   Check in autoconf that no datatype is bigger than 64, or dynar_map will
  52     get into trouble...
  53
  54 [portability layer]
  55   Dynar of type, such as ref of type
  56   Mallocators
  57
  58 [Messaging]
  59   Message forwarding
  60   Message priority
  61   Message declarations in a tree manner
  62
  63 [errors]
  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)
  71    - libgpg-error
  72
  73 [logs]
  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
  78
  79 [dict]
  80   speed up the cursors, for example using the contexts when available
  81   fix multi levels dicts
  82
  83 [datadesc]
  84   Error handling in cbps
  85   Regression tests of cbps
  86
  87 [testsuite]
  88   use logging, not printf
  89
  90 *********
  91 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
  92 *********
  93
  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).
 101
 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
 108       pour lui
 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
 114
 115     Init:
 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
 120
 121     Arrive d'un message
 122      servant:
 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)
 129      5) sem_V(sempahore)
 130      6) mutex_lock sur le mutex_verrouille
 131      sleep
 132      7) quand on revient, on rebloque un read(1), et on recommence
 133
 134      comm:
 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
 143
 144      couleur:
 145      1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
 146         prets
 147      2) on le retire de la file
 148      3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
 149         cameleon)
 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
 154           l'utilisateur)
 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
 157      Sinon
 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
 161
 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.
 165
 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.
 172
 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 ;)
 177
 178 [XML]
 179  Do what is written in the paper
 180
 181 [Macro parseuse]
 182  Gerer les typedefs (necessite de l'aide de grassouillet)
 183  Gerer les unions => specifier des annotations
 184  Gerer les enum
 185  Gerer les long long
 186  Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
 187   donnees.
 188  Verifier que "char"="signed char" sur toutes les archis
 189
 190  Renomer gs_parse_tok_num en gs_parse_token
 191  Check short a, b;
 192  Check short ***
 193  Check struct { struct { int a } b; }
 194
 195 [Grassouillet]
 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.
 198
 199 [Autres]
 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
 203
 204
 205 ************
 206 * La suite *
 207 ************
 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
 212
 213 GRAS (très):
 214  - outils mathematiques pour dire des choses sur la validite du protocole
 215