slightly busted other-child API discards interesting

information which should be available to the maintenance
function

fix in 2.0


git-svn-id: https://svn.apache.org/repos/asf/apr/apr/trunk@499417 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 14 insertions, 0 deletions

diff --git a/STATUS b/STATUS
index 81f0d9511..120cdd358 100644
--- a/STATUS
+++ b/STATUS
@@ -434,6 +434,20 @@ API Changes Postponed for APR 2.0:
       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