"Roger A. Faulkner" wrote: > > There are a number of other cases where we really > > want to create a process > > in a library where we: > > > > - don't want a SIGCHLD > > - don't want "wait on any pid" to reap it > > > > (Think of system, popen, and others were the library > > really owns the PID) > > Yes, but these cases are for when the child is > successfully created, not for when it fails along > the way to successfully calling execve(). > > I have a plan: Create variants of fork1()/forkall()/vfork() > that pass an integer argument to the kernel telling it > whether the child's death will be visible to waitpid() > for any case other than P_PID (specific pid) and, > independently, whether generation of the SIGCHLD > signal should be suppressed when the child dies. > (All of the other wait*() interfaces are simply wrappers > around waitpid().) > > The traditional fork1()/forkall()/vfork() interfaces would > simply pass zero to the kernel in the libc syscall > wrapper to get the traditional behavior.
If you do that it may be nice to add a "flags" field (e.g. 32bit unsigned integer) that future changes to these APIs can simply be done via additional flags (somehow I have the feeling this may be usefull in the not so distant future) ... it would save some trouble for the standards people since they don't have to invent new function names each time (the "posix_" prefix in |posix_spawn()| looks like as they ran out of good ideas for new names... =:-) ). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
