apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PATCH] apr function to see if an arbitrary process is alive
Date Fri, 07 Nov 2003 18:11:03 GMT
   At this point an API like apr_proc_check() would not be portable to
NetWare.  Since we own the OS, I'm sure that there is something that we
can do, but it will be a kernel enhancement for us.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> Jeff Trawick <trawick@attglobal.net> Friday, November 07, 2003
9:39:25 AM >>>
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