TODO

   1 [sorry for the parts in french :]
   2
   3 ###
   4 ### Avant 0.5
   5 ###
   6
   7 - tcp->incoming_socks
   8   sock specific tcp (buffsize) inutile
   9
  10 ###
  11 ### Avant 1.0
  12 ###
  13
  14 - renomages
  15   gras_os_time
  16   gras_os_sleep
  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 - Documentation (en particulier DD et Msg)
  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 * message forwarding
  46
  47  - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
  48  - virtualize (linux, solaris, SG) & conditions
  49  - binary representation: any type, SNWF (Sender Native Wire Format)
  50  - modules (logs, manage, token ring, bw)
  51  - cleanups, documentation
  52
  53 [autoconf]
  54   Check in autoconf that no datatype is bigger than 64, or dynar_map will
  55     get into trouble...
  56
  57 [portability layer]
  58   Dynar of type, such as ref of type
  59   Generate convertors in assembler ?
  60   Mallocators
  61
  62 [Messaging]
  63   Message forwarding
  64   Message priority
  65   Message declarations in a tree manner
  66
  67 [errors]
  68   Better split casual errors from programing errors.
  69     The first ones should be repported to the user, the second should kill
  70     the program (or, yet better, only the msg handler)
  71   Allows the use of an error handler depending on the current module (ie,
  72    the same philosophy than log4c using GSL's error functions)
  73   Rethink the error codes. Source of inspirations are:
  74    - comerr (common error reporting from ext2)
  75    - libgpg-error
  76
  77 [logs]
  78   Several appenders; fix the setting stuff to change the appender
  79   Hijack message from a given category to another for a while (to mask
  80     initializations, and more)
  81   Allow each process in simulation to have its own setting
  82
  83 [dict]
  84   dichotomie in search
  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 [Conversions inter-architectures]
 176  Marquer les padding bytes explicitement aux structures (juste le sizeof
 177    doit suffire)
 178  Marquer les offsetof des fields explicitement a l'ajout.
 179  Prevoir tous les encoding pour les types elementaires
 180    [taille, sexe, signess[non, a un, a deux]]
 181    plus les flotants, justifiant un traitement a part
 182  Tester avec autoconf les encodings sur l'archi courante
 183  Trouver un moyen de convertir un encoding en un autre (si possible par
 184    blocs)
 185  Generer ces convertors en assembleur a chaud, puisqu'on a rien de mieux a
 186    foutre de notre temps
 187
 188 [XML]
 189  Tout comme c'est dit dans les articles
 190
 191 [Macro parseuse]
 192  Gerer les typedefs (necessite de l'aide de grassouillet)
 193  Gerer les pointeurs.
 194    Faut des annotations pour dire si c'est :
 195     - un AZT
 196     - un tableau dont la longueur est ailleurs dans la struct
 197     - une ref
 198    Ca peut se faire soit avec des commentaires, soit avec des macros se
 199      reecrivant a rien dans la vraie vie, et parsee. Mais le risque est que
 200      ces macros soient reecrites avant d'etre passee a mon bordel, selon les
 201      cpp.
 202  Gerer les unions => specifier des annotations, mais j'y crois pas
 203  Gerer les enum
 204  Gerer les long long
 205  Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
 206   donnees.
 207  Verifier que "char"="signed char" sur toutes les archis
 208
 209  Renomer gs_parse_tok_num en gs_parse_token
 210  Check short a, b;
 211  Check short ***
 212  Check struct { struct { int a } b; }
 213
 214 [Grassouillet]
 215  Gerer les typedefs pour aliaser un type sur un autre
 216  Merger gs_type_union_append_field et gs_type_struc_append_field si possible.
 217  Gerer les enum ?
 218  gs_type_copy/gs_type_free
 219  A quoi sert le champ name de gs_type_struct_append_field ?
 220  Ca plante bizarement si on met une structure n'existant pas dans le
 221    message (a l'usage)
 222  gs_type_dump, nardin, comment voir ce qui se passe sinon ??
 223
 224 [Autres]
 225  Faire toutes les modifs aux Utils listees plus haut
 226  Simplifier l'envoi de dynar et dico
 227  Mettre les mutex et semaphores dans les dynar directement
 228  Tenter (politiquement) le passage a GPL, pour voler du code.
 229
 230
 231 ************
 232 * La suite *
 233 ************
 234 GRAS double (ou encore "GRAS too" ou "too GRAS"):
 235  - Priorite des messages
 236  - Outils de visu pour ce qui se passe dans le simulo
 237  - Outils de visu/deployement/management pour RL
 238
 239 GRAS (très):
 240  - outils mathematiques pour dire des choses sur la validite du protocole
 241