[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-cvs
Subject:    svn commit: r499417 - /apr/apr/trunk/STATUS
From:       trawick () apache ! org
Date:       2007-01-24 14:30:55
Message-ID: 20070124143056.126D41A981C () eris ! apache ! org
[Download RAW message or body]

Author: trawick
Date: Wed Jan 24 06:30:55 2007
New Revision: 499417

URL: http://svn.apache.org/viewvc?view=rev&rev=499417
Log:
slightly busted other-child API discards interesting
information which should be available to the maintenance
function

fix in 2.0

Modified:
    apr/apr/trunk/STATUS

Modified: apr/apr/trunk/STATUS
URL: http://svn.apache.org/viewvc/apr/apr/trunk/STATUS?view=diff&rev=499417&r1=499416&r2=499417
==============================================================================
--- apr/apr/trunk/STATUS (original)
+++ apr/apr/trunk/STATUS Wed Jan 24 06:30:55 2007
@@ -434,6 +434,20 @@
       would be slightly faster, for what's likely to be little impact on
       performance.
 
+    * The other-child API doesn't allow the apr_exit_why_e to be passed to the
+      application's maintenance function.  The expected usage is that the
+      application calls apr_proc_wait[_all_procs]() and is given back
+      apr_exit_why_e and exit_code_or_signal_num, thus losing the original
+      (on Unix, at least) representation which held both pieces of information
+      in an int.  Both pieces of data should be available to the maintenance 
+      function so that it has the opportunity to take different actions.  An
+      example would be to issue messages about probable misconfiguration when
+      receiving a certain exit code and trying to restart otherwise.  Thus, 
+      apr_proc_other_child_alert() should take an additional apr_exit_why_e 
+      parameter, as should the application-provided maintenance function.  The 
+      exit-why value would be ignored in the same circumstances as the existing 
+      status parameter: reason != APR_OC_REASON_DEATH.
+
 Stuff for post 1.0:
 
     * Almost every API in APR depends on pools, but pool semantics


[prev in list] [next in list] [prev in thread] [next in thread]