-[sorry for the parts in french :]
-
-###
-### Avant 0.5
-###
-
-- tcp->incoming_socks
- sock specific tcp (buffsize) inutile
-
###
-### Avant 1.0
+### Ongoing stuff
###
-- renomages
- gras_os_time
- gras_os_sleep
- gras_os_getload
-
-- gras_datadesc_import_nws
+Document the fact that gras processes display the backtrace on sigusr and sigint
+Document XBT_LOG_EXTERNAL_DEFAULT_CATEGORY
+Document host module
-- rawsock
- Verifier que les messages vont pas sur des sock raw
+/* FIXME: better place? */
+int vasprintf (char **ptr, const char *fmt, va_list ap);
+char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
-- Documentation (en particulier DD et Msg)
+Module renamings:
+ - rename SWAG to RING?
+ - Rename cursor to iterator
-- gras_datadesc_cpy -> donne la taille prise pour donner un poids aux messages
-
-- callback en reception ?? (remettre les pointeurs sur fonction etc)
-
-- Virer cat ignored
- gras_ddt_new_ignored : Pas portable (taille) => virer cat?
- Necessaire aux pointeurs sur fonction? Renomer 'void'
+gras_socket_close should be blocking until all the data sent have been
+received by the other side (implemented with an ACK mechanism).
###
-### Apres
-###
-
-- Adaptative timeout
-- datadesc_set_cste: Donne la valeur par defaut en reception
- plus de transfert, ce qui est utile pour les pointeurs sur fct
+### Planned
+###
-============================================================================
+*
+* Infrastructure
+****************
-* while (1) { fork; exec the child, wait in father }
-* message forwarding
+[autoconf]
+ * Check the gcc version on powerpc. We disabled -floop-optimize on powerpc,
+ but versions above 3.4.0 should be ok.
+ * check whether we have better than jmp_buf to implement exceptions, and
+ use it (may need to generate a public .h, as glib does)
- - 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 (logs, manage, token ring, bw)
- - cleanups, documentation
+*
+* XBT
+*****
-[autoconf]
- Check in autoconf that no datatype is bigger than 64, or dynar_map will
- get into trouble...
+[doc]
+ * graphic showing:
+ (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
[portability layer]
- Dynar of type, such as ref of type
- Generate convertors in assembler ?
- Mallocators
-
-[Messaging]
- Message forwarding
- Message priority
- Message declarations in a tree manner
-
-[errors]
- Better split casual errors from programing errors.
+ * maybe a memory pool so that we can cleanly kill an actor
+
+[errors/exception]
+ * Better split casual errors from programing errors.
The first ones should be repported 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]
- dichotomie in search
- speed up the cursors, for example using the contexts when available
- fix multi levels dicts
+ * Allow each actor to have its own setting
+ * a init/exit mecanism for logging appender
+ * Several appenders; fix the setting stuff to change the appender
+ * more logging appenders (take those from Ralf in l2)
+
+[modules]
+ * Add configuration and dependencies to our module definition
+ * allow to load them at runtime
+ check in erlang how they upgrade them without downtime
+
+[other modules]
+ * we may need a round-robin database module, and a statistical one
+ * a hook module *may* help cleaning up some parts. Not sure yet.
+ * Some of the datacontainer modules seem to overlap. Kill some of them?
+ - replace fifo with dynars
+ - replace set with SWAG
+
+*
+* GRAS
+******
+
+[doc]
+ * implement the P2P protocols that macedon does. They constitute great
+ examples, too
+
+[transport]
+ * Spawn threads handling the communication
+ - Data sending cannot be delegated if we want to be kept informed
+ (*easily*) of errors here.
+ - Actor execution flow shouldn't be interrupted
+ - It should be allowed to access (both in read and write access)
+ any data available (ie, referenced) from the actor without
+ requesting to check for a condition before.
+ (in other word, no mutex or assimilated)
+ - I know that enforcing those rules prevent the implementation of
+ really cleaver stuff. Keeping the stuff simple for the users is more
+ important to me than allowing them to do cleaver tricks. Black magic
+ should be done *within* gras to reach a good performance level.
+
+ - Data receiving can be delegated (and should)
+ The first step here is a "simple" mailbox mecanism, with a fifo of
+ messages protected by semaphore.
+ The rest is rather straightforward too.
+
+ * use poll(2) instead of select(2) when available. (first need to check
+ the advantage of doing so ;)
+
+ Another idea we spoke about was to simulate this feature with a bunch of
+ threads blocked in a read(1) on each incomming socket. The latency is
+ reduced by the cost of a syscall, but the more I think about it, the
+ less I find the idea adapted to our context.
+
+ * timeout the send/recv too (hard to do in RL)
+ * Adaptative timeout
+ * multiplex on incoming SOAP over HTTP (once datadesc can deal with it)
+
+ * The module syntax/API is too complex.
+ - Everybody opens a server socket (or almost), and nobody open two of
+ them. This should be done automatically without user intervention.
+ - I'd like to offer the possibility to speak to someone, not to speak on
+ a socket. Users shouldn't care about such technical details.
+ - the idea of host_cookie in NWS seem to match my needs, but we still
+ need a proper name ;)
+ - this would allow to exchange a "socket" between peer :)
+ - the creation needs to identify the peer actor within the process
+
+ * when a send failed because the socket was closed on the other side,
+ try to reopen it seamlessly. Needs exceptions or another way to
+ differentiate between the several system_error.
+ * cache accepted sockets and close the old ones after a while.
+ Depends on the previous item; difficult to achieve with firewalls
[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.
-
-[Conversions inter-architectures]
- Marquer les padding bytes explicitement aux structures (juste le sizeof
- doit suffire)
- Marquer les offsetof des fields explicitement a l'ajout.
- Prevoir tous les encoding pour les types elementaires
- [taille, sexe, signess[non, a un, a deux]]
- plus les flotants, justifiant un traitement a part
- Tester avec autoconf les encodings sur l'archi courante
- Trouver un moyen de convertir un encoding en un autre (si possible par
- blocs)
- Generer ces convertors en assembleur a chaud, puisqu'on a rien de mieux a
- foutre de notre temps
-
-[XML]
- Tout comme c'est dit dans les articles
-
-[Macro parseuse]
- Gerer les typedefs (necessite de l'aide de grassouillet)
- Gerer les pointeurs.
- Faut des annotations pour dire si c'est :
- - un AZT
- - un tableau dont la longueur est ailleurs dans la struct
- - une ref
- Ca peut se faire soit avec des commentaires, soit avec des macros se
- reecrivant a rien dans la vraie vie, et parsee. Mais le risque est que
- ces macros soient reecrites avant d'etre passee a mon bordel, selon les
- cpp.
- Gerer les unions => specifier des annotations, mais j'y crois pas
- Gerer les enum
- Gerer les long long
- Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
- donnees.
- Verifier que "char"="signed char" sur toutes les archis
-
- Renomer gs_parse_tok_num en gs_parse_token
- Check short a, b;
- Check short ***
- Check struct { struct { int a } b; }
-
-[Grassouillet]
- Gerer les typedefs pour aliaser un type sur un autre
- Merger gs_type_union_append_field et gs_type_struc_append_field si possible.
- Gerer les enum ?
- gs_type_copy/gs_type_free
- A quoi sert le champ name de gs_type_struct_append_field ?
- Ca plante bizarement si on met une structure n'existant pas dans le
- message (a l'usage)
- gs_type_dump, nardin, comment voir ce qui se passe sinon ??
-
-[Autres]
- Faire toutes les modifs aux Utils listees plus haut
- Simplifier l'envoi de dynar et dico
- Mettre les mutex et semaphores dans les dynar directement
- Tenter (politiquement) le passage a GPL, pour voler du code.
+ * Add a XML wire protocol alongside to the binary one (for SOAP/HTTP)
+ * cbps:
+ - Error handling
+ - Regression tests
+ * Inter-arch conversions
+ - Port to ARM
+ - 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 ;)
+ * datadesc_set_cste: give the value by default when receiving.
+ - It's not transfered anymore, which is good for functions pointer.
+ * Parsing macro
+ - Cleanup the code (bison?)
+ - Factorize code in union/struct field adding
+ - Handle typedefs (gras_datatype_copy can be usefull, but only if
+ main type is already defined)
+ - 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; }
+
+ * gras_datadesc_import_nws?
-************
-* La suite *
-************
-GRAS double (ou encore "GRAS too" ou "too GRAS"):
- - Priorite des messages
- - Outils de visu pour ce qui se passe dans le simulo
- - Outils de visu/deployement/management pour RL
-
-GRAS (très):
- - outils mathematiques pour dire des choses sur la validite du protocole
-
+[Messaging]
+ * Other message types than oneway & RPC are possible:
+ - forwarding request, group communication
+ * Message priority
+ * Message forwarding
+ * Group communication
+ * Message declarations in a tree manner (such as log channels)?
+
+[GRASPE] (platform expender)
+ * Tool to visualize/deploy and manage in RL
+ * pull method of source diffusion in graspe-slave
+
+[Actors] (parallelism in GRAS)
+ * An actor is a user process.
+ It has a highly sequential control flow from its birth until its death.
+ The timers won't stop the current execution to branch elsewhere, they
+ will be delayed until the actor is ready to listen. Likewise, no signal
+ delivery. The goal is to KISS for users.
+ * You can fork a new actor, even on remote hosts.
+ * They are implemented as threads in RL, but this is still a distributed
+ memory *model*. If you want to share data with another actor, send it
+ using the message interface to explicit who's responsible of this data.
+ * data exchange between actors placed within the same UNIX process is
+ *implemented* by memcopy, but that's an implementation detail.
+
+[Other, more general issues]
+ * watchdog in RL (ie, while (1) { fork; exec the child, wait in father })
+ * Allow [homogeneous] dico to be sent
+ * Make GRAS thread safe by mutexing what needs to be
+
+*
+* AMOK
+******
+
+[bandwidth]
+ * add a version guessing the appropriate datasizes automatically
+[other modules]
+ * provide a way to retrieve the host load as in NWS
+ * log control, management, dynamic token ring
+ * a way using SSH to ask a remote host to open a socket back on me
+
\ No newline at end of file