Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
model-checker : free pointers
[simgrid.git] / TODO
diff --git a/TODO b/TODO
index 61f9f9a..9176059 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,18 +1,26 @@
+
+
+
+
+                ************************************************
+                ***  This file is a TODO. It is thus kinda   ***
+                ***  outdated. You know the story, right?    ***
+                ************************************************
+
+
+
+
 ###
 ### Ongoing stuff
 ###
 
 Document the fact that gras processes display the backtrace on sigusr and sigint
 ###
 ### Ongoing stuff
 ###
 
 Document the fact that gras processes display the backtrace on sigusr and sigint
-Document XBT_LOG_EXTERNAL_DEFAULT_CATEGORY
 Document host module
 
 /* FIXME: better place? */
 int vasprintf  (char **ptr, const char *fmt, va_list ap);
 char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
 
 Document host module
 
 /* FIXME: better place? */
 int vasprintf  (char **ptr, const char *fmt, va_list ap);
 char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
 
-Module renamings:
- - rename SWAG to RING?
- - Rename cursor to iterator
 
 gras_socket_close should be blocking until all the data sent have been
 received by the other side (implemented with an ACK mechanism).
 
 gras_socket_close should be blocking until all the data sent have been
 received by the other side (implemented with an ACK mechanism).
@@ -25,7 +33,7 @@ received by the other side (implemented with an ACK mechanism).
 * Infrastructure
 ****************
 
 * Infrastructure
 ****************
 
-[autoconf]
+[build chain]
   * 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
   * 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
@@ -35,16 +43,9 @@ received by the other side (implemented with an ACK mechanism).
 * XBT
 *****
 
 * XBT
 *****
 
-[doc]
-  * graphic showing:
-    (errors, logs ; dynars, dicts, hooks, pools; config, rrdb)
-
-[portability layer]
-  * maybe a memory pool so that we can cleanly kill an actor
-
 [errors/exception]
 [errors/exception]
-  * Better split casual errors from programing errors.
-    The first ones should be repported to the user, the second should kill
+  * 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 as log4c using GSL's error functions)
     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 as log4c using GSL's error functions)
@@ -53,8 +54,6 @@ received by the other side (implemented with an ACK mechanism).
   * Hijack message from a given category to another for a while (to mask
     initializations, and more)
   * Allow each actor to have its own setting
   * Hijack message from a given category to another for a while (to mask
     initializations, and more)
   * 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]
   * more logging appenders (take those from Ralf in l2)
 
 [modules]
@@ -64,7 +63,6 @@ received by the other side (implemented with an ACK mechanism).
 
 [other modules]
   * we may need a round-robin database module, and a statistical one
 
 [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
   * Some of the datacontainer modules seem to overlap. Kill some of them?
     - replace fifo with dynars
     - replace set with SWAG
@@ -78,29 +76,11 @@ received by the other side (implemented with an ACK mechanism).
     examples, too
 
 [transport]  
     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
   * 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
+    threads blocked in a read(1) on each incoming 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.
 
     reduced by the cost of a syscall, but the more I think about it, the
     less I find the idea adapted to our context.
 
@@ -133,13 +113,13 @@ received by the other side (implemented with an ACK mechanism).
     - Port to ARM
     - Convert in the same buffer when size increase
     - Exchange (on net) structures in one shoot when possible.
     - 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
   * 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 (needs love from DataDesc/)
+    - 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
     - Handle unions with annotate
     - Handle enum
     - Handle long long and long double
@@ -152,8 +132,6 @@ received by the other side (implemented with an ACK mechanism).
     - Check short ***
     - Check struct { struct { int a } b; } 
 
     - Check short ***
     - Check struct { struct { int a } b; } 
 
-  * gras_datadesc_import_nws?
-
 [Messaging]
   * Other message types than oneway & RPC are possible:
      - forwarding request, group communication
 [Messaging]
   * Other message types than oneway & RPC are possible:
      - forwarding request, group communication
@@ -162,23 +140,6 @@ received by the other side (implemented with an ACK mechanism).
   * Group communication
   * Message declarations in a tree manner (such as log channels)?
   
   * 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
 [Other, more general issues]
   * watchdog in RL (ie, while (1) { fork; exec the child, wait in father })
   * Allow [homogeneous] dico to be sent
@@ -191,7 +152,6 @@ received by the other side (implemented with an ACK mechanism).
 [bandwidth]
   * add a version guessing the appropriate datasizes automatically
 [other modules]
 [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
   * 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