Maxim Sobolev wrote:
Ed Schouten wrote:
* David Schultz <[EMAIL PROTECTED]> wrote:
I have no objections to this, but doesn't it defeat the whole
purpose to implement posix_spawn() as a library function that just
calls fork/exec?
When (if?) applications start to use posix_spawn() we may decide to move
it into the kernel at any time. It should be okay for now.
Are there any benefits of doing it in the kernel vs. doing it via
fork+exec?
-Maxim
I just want to make some programs to work, since Linux and Solaris
both have it now. Doing it in kernel is OK, but I don't want to put
it into the kernel until it is necessary since kernel code can not
be swapped out. ;-)
Doing in kernel may have advantages, for example, you may get ride
of zoombie process recycling by hacking kernel, a library version
using vfork will need parent to handle SIGCHLD and recycle zoombie
process like you use popen() and system() etcs, another advantage
is it won't involve rtld if a symbol needs to resolved, because
vfork shares same vmspace, it might block other threads in
parent process if the child process holding a rtld's
reader lock, I don't know if writer lock will be held in child,
I guess it won't be. if the child process get killed wrongly
by someone, it might hold reader lock forever, this is the race
condition. a kernel version may have trouble if something can not
be easily done in kernel, though I didn't find the one can not
be done in kernel at present.
Regards,
David Xu
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
