Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Add a state SD_READY to the tasks to optimize SD_simulate
[simgrid.git] / TODO
diff --git a/TODO b/TODO
index ba43258..bd0098b 100644 (file)
--- a/TODO
+++ b/TODO
@@ -5,13 +5,20 @@
 int vasprintf  (char **ptr, const char *fmt, va_list ap);
 char *bprintf(const char*fmt, ...) _XBT_GNUC_PRINTF(1,2);
 
-Replace fifo with dynars
+Module renamings:
+ - rename SWAG to RING?
+ - Rename cursor to iterator
 
-Replace set with SWAG
+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
 
-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).
 
 ###
 ### Planned
@@ -58,7 +65,9 @@ Rename cursor to iterator
 
 [modules]
   * better formalisation of what modules are (amok deeply needs it)
-    configuration + init() + exit() + dependencies
+    configuration + init() + join() + exit() + leave() + dependencies
+    init and exit are run only once
+    join and leave are run for each process.
   * allow to load them at runtime
     check in erlang how they upgrade them without downtime
 
@@ -66,6 +75,8 @@ Rename cursor to iterator
   * 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
@@ -160,18 +171,8 @@ Rename cursor to iterator
   * gras_datadesc_import_nws?
 
 [Messaging]
-  * A proper RPC mecanism
-    - gras_rpctype_declare_v (name,ver, payload_request, payload_answer)
-      (or gras_msgtype_declare_rpc_v). 
-    - Attaching a cb works the same way.
-    - gras_msg_rpc(peer, &request, &answer)
-    - On the wire, a byte indicate the message type:
-      - 0: one-way message (what we have for now)
-      - 1: method call (answer expected; sessionID attached)
-      - 2: successful return (usual datatype attached, with sessionID)
-      - 3: error return (payload = exception)
-      - other message types are possible (forwarding request, group
-        communication)
+  * Other message types than oneway & RPC are possible:
+     - forwarding request, group communication
   * Message priority
   * Message forwarding
   * Group communication