On Mon, Jan 07, 2002 at 11:27:53PM -0800, Aaron Bannert wrote:
> I think we should take the fork() stuff out of apr_proc_detach()
> instead. Detach is doing what it's supposed to, creating a new session
> (and therefore detaching from the controlling terminal). The only way
> it can reliably do that is if it is not a pgrp leader. IMO the way
> to handle this is to let apr_proc_deatch() assume it is already a
> non pgrp leader and put the fork() calls that ensure this outside.
What about the reopening of fd 0-2 that also happens inside apr_proc_detach()?
We probably don't want that to happen with NO_DETACH (my latest patch fixes
this).
> Another option is to have apr_proc_deatch() simply check if it is
> the pgrp leader, and if so to only then call the fork.
Wouldn't we need to create a new apr_ function to perform this check because
it calls the platform-specific getpgrp()/... functions? I'm assuming that the
pgrp leader check simply involves checking if getpgrp() == getpid(). Correct?
--
Jos Backus _/ _/_/_/ Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/ _/
[EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
