-- a way to get the network proximity (needed by Pastry, at least)
-- pull method of source diffusion in graspe-slave
+###
+### Urgent stuff:
+###
+
+* Have a proper todo file
+
+
+
+
-- Use a xbt_set for gras_procdata_t->libdata instead of a dict
- so that the search can be linear.
-[sorry for the parts in french :]
-###
-### Very soon
-###
-- tcp->incoming_socks
- sock specific tcp (buffsize) useless
+ ************************************************
+ *** This file is a TODO. It is thus kinda ***
+ *** outdated. You know the story, right? ***
+ ************************************************
+
+
+
###
-### Soon
+### Ongoing stuff
###
-- gras_os_getload
+Document host module
-- gras_datadesc_import_nws?
+/* FIXME: better place? */
+int vasprintf (char **ptr, const char *fmt, va_list ap);
+char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
-- rawsock
- Check that messages don't go on raw socks
- Rename to meassock or whatever to show that they're not intended for
- out of band communication, but for socket operation measurements.
+###
+### Planned
+###
-- Implement gras_datadesc_cpy to speedup things in the simulator
- For now, we mimick closely the RL when on simulator, which is not needed.
- (this was easier to do).
- gras_datadesc_cpy needs to provide the size of the corresponding messages, so
- that we can report it into the simulator.
+*
+* XBT
+*****
-###
-### A bit later
-###
-
-- Adaptative timeout
-- datadesc_set_cste: give the value by default when receiving.
- It's not transfered anymore, which is good for functions pointer.
-
-============================================================================
-
-* while (1) { fork; exec the child, wait in father }
-
- - core ok (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
- - virtualize (linux, solaris, SG) & conditions
- - binary representation: any type, SNWF (Sender Native Wire Format)
- - modules (log control, manage, token ring, bw)
- - cleanups, documentation
-
-[autoconf]
- Check the gcc version on powerpc. We disabled -floop-optimize on powerpc,
- but versions above 3.4.0 should be ok.
- The ucontext usability test is too light. It returns success on IRIX, but
- shouldn't since ucontext are broken for us there.
-
-[portability layer]
- Mallocators
-
-[Messaging]
- Message forwarding
- Message priority
- Message declarations in a tree manner (such as log channels)
-
-[errors]
- Better split casual errors from programing errors.
- The first ones should be repported to the user, the second should kill
+[errors/exception]
+ * Better split casual errors from programming errors.
+ The first ones should be reported to the user, the second should kill
the program (or, yet better, only the msg handler)
- Allows the use of an error handler depending on the current module (ie,
- the same philosophy than log4c using GSL's error functions)
- Rethink the error codes. Source of inspirations are:
- - comerr (common error reporting from ext2)
- - libgpg-error
+ * Allows the use of an error handler depending on the current module (ie,
+ the same philosophy as log4c using GSL's error functions)
[logs]
- Several appenders; fix the setting stuff to change the appender
- Hijack message from a given category to another for a while (to mask
+ * Hijack message from a given category to another for a while (to mask
initializations, and more)
- Allow each process in simulation to have its own setting
-
-[dict]
- speed up the cursors, for example using the contexts when available
- fix multi levels dicts
-
-[datadesc]
- Error handling in cbps
- Regression tests of cbps
-
-*********
-* GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
-*********
-
-[simuler le select sur les sockets avec des threads]
- Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
- charge de faire du pool blocant dessus, et des que ce thread se debloque
- car il commence a lire qqch, il passe la main a un thread de
- communication charge de faire la lecture.
- Quand la lecture est finie, le thread de comm passe la main aux threads
- d'execution (un par couleur).
-
- Voici comment faire le coeur du truc [dixit Olivier]:
- Une liste est utilisee pour stocker ce que le thread de comm a le droit
- de lire. Elle est protegee par mutex pour eviter les acces concurents.
- c'est la "liste de lecture"
- Une semaphore "de lecture" est utilisee pour permettre aux threads
- servants des sockets de prevenir le thread de comm qu'ils ont qqch
- pour lui
- Dans la liste de lecture, on place les messages en cours de creation, et
- un ptit mutex pour que le thread de comm dise aux threads servants de
- retourner ecouter la socket car il a fini
- Chaque couleur a sa file de callback a appeller, proteger par semaphore
- et un mutex comme pour la file de lecture
-
- Init:
- initialisation de toutes les semaphore a 0
- comm: sem_P(semaphore lecture)
- couleur: sem_P(semaphore de la couleur correspondante)
- servant: read (1) sur la socket
-
- Arrive d'un message
- servant:
- 1) le read debloque (c'est la version de gras, utilisee pour multiplexe
- sur le XML, ou sur les differentes versions de gras/de pilote reseau)
- 2) Allocation du message vide pour contenir ce qui s'annonce
- 3) initialisation du mutex du message_instance a 0 (verrouille)
- 4) placement du message instance dans la file (prise de mutex,
- placement, lachage de mutex)
- 5) sem_V(sempahore)
- 6) mutex_lock sur le mutex_verrouille
- sleep
- 7) quand on revient, on rebloque un read(1), et on recommence
-
- comm:
- 1) on se reveille quand la semaphore se libere (etape 6 des servants)
- 2) prise d'une tache dans la file (protegee par semaphore)
- 3) lecture de l'instance de message
- 4) lache le mutex dans l'instance pour liberer le servant
- 5) pose le message pret dans la file de la couleur correpondant au
- premier callback de la pile pour ces {messageID x version} et
- augmente le semaphore correspondant.
- 6) se rebloque sur le semaphore de lecture et recommence
-
- couleur:
- 1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
- prets
- 2) on le retire de la file
- 3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
- cameleon)
- 4) on execute le callback qu'il faut
- 5) on lache le mutex de sa couleur
- Si le callback annonce avoir mange le message
- a) on libere le message (le payload doit avoir ete libere par
- l'utilisateur)
- b) on decremente le TTL du callback, et on le vire si c'etait pas un
- callback infini et qu'il arrive en fin de vie
- Sinon
- a) on place le message dans la liste des messages de la couleur du
- suivant dans la pile des callback
- 6) On se rendort sur le semaphore de sa couleur et recommence
-
- Emission d'un message:
- A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
- thread de comm pour cela.
-
- Fermeture d'une socket client:
- Probleme: faut tuer le thread servant.
- Solution pour l'instant: fermer la socket depuis ailleurs.
- Solution si ca marche pas (ou pas partout): Les servants font des
- selects sur un pool {leur socket x un pipe fait pour}
- Quand qqch arrive sur le pipe, c'est le signal du suicide.
-
-[Inter-arch conversions]
- Convert in the same buffer when size increase
- Exchange (on net) structures in one shoot when possible.
- Port to really exotic platforms (Cray is not IEEE ;)
-
-[XML]
- Do what is written in the paper (multiplex on incoming HTTP)
-
-[DataDesc and Parsing macro]
- Handle typedefs (needs love from DataDesc/)
- Handle unions with annotate
- Handle enum
- Handle long long and long double
- Forbid "char", allow "signed char" and "unsigned char", or user code won't be
- portable to ARM, at least.
- Handle struct/union/enum embeeded within another container
- (needs modifications in DataDesc, too)
-
- Check short a, b;
- Check short ***
- Check struct { struct { int a } b; }
-
- Factorize code in union/struct field adding
-
-[Other]
- Allow [homogeneous] dico to be sent
- Make GRAS thread safe by mutexing what needs to be
-
-
-************
-* La suite *
-************
-GRAS double (ou encore "GRAS too" ou "too GRAS"):
- - Message prioritization
- - Visualisation tool to see what happens in the simulator (Paje ?)
- - Tool to visualize/deploy and manage in RL
-
-GRAS (très):
- - outils mathematiques pour dire des choses sur la validite du protocole
-
+ * Allow each actor to have its own setting
+ * more logging appenders (take those from Ralf in l2)
+
+[modules]
+ * Add configuration and dependencies to our module definition
+
+[other modules]
+ * we may need a round-robin database module, and a statistical one
+ * Some of the datacontainer modules seem to overlap. Kill some of them?
+ - replace fifo with dynars
+ - replace set with SWAG
