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 <[EMAIL PROTECTED]> 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
