At 09:23 AM 11/7/2003, Jeff Trawick wrote:
>see patch... seems simple enough, but perhaps somebody knows some
>showstoppers that would prevent this from being implemented on some platform?
No, but the code's behavior is definitely not portable, and will make the user's
code very buggy...
>+APR_DECLARE(apr_status_t) apr_proc_check(apr_proc_t *proc)
>+{
>+#ifdef _AIX
>+ /* On AIX, for processes like mod_cgid's script children where
>+ * SIGCHLD is ignored, kill(pid,0) returns success for up to
>+ * one second after the script child exits, based on when a
>+ * daemon runs to clean up unnecessary process table entries.
>+ * getpgid() can report the proper info (-1/ESRCH) immediately.
>+ */
>+ return (getpgid(proc->pid) < 0) ? errno : APR_SUCCESS;
>+#else
>+ return (kill(proc->pid, 0) < 0) ? errno : APR_SUCCESS;
>+#endif
>+}
Wham. Zombie gone, result code not longer recoverable, if I understand
things correctly? Solution is probably to cache all the resulting info within
the apr_proc_t structure when the child is mopped up by any apr call, and
let all of these status functions check that before looking at the actual
process itself.
Second problem - will the users registered otherchild handler still be called?
I would say yes - it must be to be consistent - so if 'something changed' here,
we should react - immediately or no?
Bill
