Enlightenment CVS committal

Author  : onefang
Project : e17
Module  : libs/ecore

Dir     : e17/libs/ecore/src/lib/ecore


Modified Files:
        ecore_private.h 


Log Message:
Documentation of issues involved with implementing respawn.

===================================================================
RCS file: /cvsroot/enlightenment/e17/libs/ecore/src/lib/ecore/ecore_private.h,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -3 -r1.29 -r1.30
--- ecore_private.h     30 Dec 2005 19:17:21 -0000      1.29
+++ ecore_private.h     4 Jan 2006 16:33:25 -0000       1.30
@@ -154,6 +154,62 @@
    ECORE_EXE_PIPE_WRITE = 2,
    ECORE_EXE_PIPE_READ_LINE_BUFFERED = 4,
    ECORE_EXE_RESPAWN = 8
+   /* FIXME: Getting respawn to work
+    *
+    * There is no way that we can do anything about the internal state info of
+    * an external exe.  The same can be said about the state of user code.  
User
+    * code in this context means the code that is using ecore_exe to manage 
exe's
+    * for it.
+    *
+    * Document that the exe must be respawnable, in other words, there is no
+    * state that it cannot regenerate by just killing it and starting it again.
+    * This includes state that the user code knows about, as the respawn is 
+    * transparent to that code.  On the other hand, maybe a respawn event 
might 
+    * be useful, or maybe resend the currently non existant add event.  For 
+    * consistancy with ecore_con, an add event is good anyway.
+    *
+    * The Ecore_exe structure is reused for respawning, so that the (opaque)
+    * pointer held by the user remains valid.  This means that the Ecore_Exe
+    * init and del functions may need to be split into two parts each to avoid 
+    * duplicating code - common code part, and the rest.  This implies that
+    * the unchanging members mentioned next should NEVER change.
+    *
+    * These structure members don't need to change -
+    *   __list_data       - we stay on the list
+    *   ECORE_MAGIC       - this is a constant
+    *   data              - passed in originally
+    *   cmd               - passed in originally
+    *   flags             - passed in originally
+    *
+    * These structure members need to change -
+    *   tag               - state that must be regenerated, zap it
+    *   pid               - it will be different
+    *   child_fd_write    - it will be different
+    *   child_fd_read     - it will be different
+    *   write_fd_handler  - we cannot change the fd used by a handler, this 
changes coz the fd changes.
+    *   read_fd_handler   - we cannot change the fd used by a handler, this 
changes coz the fd changes.
+    *
+    * Hmm, the read and write buffers could be tricky.
+    * They are not atomic, and could be in a semi complete state.
+    * They fall into the "state must be regenerated" mentioned above.
+    * A respawn/add event should take care of it.
+    *
+    * These structure members need to change -
+    *   write_data_buf    - state that must be regenerated, zap it
+    *   write_data_size   - state that must be regenerated, zap it
+    *   write_data_offset - state that must be regenerated, zap it
+    *   read_data_buf     - state that must be regenerated, zap it
+    *   read_data_size    - state that must be regenerated, zap it
+    *   close_write       - state that must be regenerated, zap it
+    *
+    * There is the problem that an exe that fell over and needs respawning
+    * might keep falling over, keep needing to be respawned, and tie up system 
+    * resources with the constant respawning.  An exponentially increasing 
+    * timeout (with maximum timeout) between respawns should take care of that.
+    * Although this is not a "contention for a resource" problem, the exe 
falling 
+    * over may be, so a random element added to the timeout may help, and 
won't 
+    * hurt.  The user code may need to be informed that a timeout is in 
progress. 
+    */
 };
 typedef enum _Ecore_Exe_Flags Ecore_Exe_Flags;
 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-cvs mailing list
enlightenment-cvs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs

Reply via email to