Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Remove useless defines.
[simgrid.git] / TODO
diff --git a/TODO b/TODO
index 499b848..9176059 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,26 +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
-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);
 
-Module renamings:
- - rename SWAG to RING?
- - Rename cursor to iterator
-
-log.h still contains @name which break doxygen:
-xbt/log.h:/** \name DEBUG
-xbt/log.h:/** \name VERB
-xbt/log.h:/** \name INFO
-xbt/log.h:/** \name WARN
-xbt/log.h:/** \name ERROR
-xbt/log.h:/** \name CRITICAL
 
 gras_socket_close should be blocking until all the data sent have been
 received by the other side (implemented with an ACK mechanism).
@@ -33,7 +33,7 @@ received by the other side (implemented with an ACK mechanism).
 * 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
@@ -43,16 +43,9 @@ received by the other side (implemented with an ACK mechanism).
 * 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]
-  * 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)
@@ -61,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
-  * 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]
@@ -72,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
-  * 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
@@ -86,29 +76,11 @@ received by the other side (implemented with an ACK mechanism).
     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
+    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.
 
@@ -141,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 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 (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
@@ -160,8 +132,6 @@ received by the other side (implemented with an ACK mechanism).
     - 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
@@ -170,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)?
   
-[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
@@ -199,7 +152,6 @@ received by the other side (implemented with an ACK mechanism).
 [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