cvs commit: src/include Makefile spawn.h unistd.h src/lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c posix_spawn.c

[David Xu]

Maxim Sobolev wrote:
> Ed Schouten wrote:
>> * David Schultz <das at FreeBSD.ORG> 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