apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: [PATCH] apr function to see if an arbitrary process is alive
Date Fri, 07 Nov 2003 16:39:25 GMT
William A. Rowe, Jr. wrote:

> 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...

well, this is what I was fishing for...  what isn't portable?  can a program 
not check to see if some unrelated process is still alive on 
{win32,netware,os/2,whatever}?

>>+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?

no, what makes a zombie go away?  this just queries the kernel to see if the 
pid is valid...  it does not affect the process at all

> 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?

this is intended to be unrelated to otherchild stuff... given that the process 
being checked for is not affected, it shouldn't change how otherchild stuff works



Mime
View raw message