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

[Robert Watson]

On Tue, 17 Jun 2008, David Schultz wrote:

> On Tue, Jun 17, 2008, 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?
>
> The only reason spawn exists is to better support platforms where fork is 
> slow, so implementing it in terms of fork/exec defeats the purpose and 
> potentially tricks configure scripts into making incorrect assumptions about 
> performance tradeoffs. However, maybe spawn would still be useful if 
> misguided application writers used it for other reasons (e.g., to make it 
> easier to port Win32 apps), and I'm guessing that's why it was added. 
> Implementing it in the kernel has disadvantages, too; in particular, it 
> would add a lot of complexity for gains that are likely to be minimal in 
> FreeBSD.

Apple's experience has been somewhat to the contrary -- while the architecture 
varies some by OS release, one of the persisting performance problems they 
were seeing was the cost of fork()+execve() from applications with very large 
numbers of shared libraries, plugins, memory mappings, etc.  Currently, they 
address this by having a process launch applications "by proxy" as a result of 
IPC requests instead of forking and execing, but you might reasonably argue 
that the problem is with the fork()+execve() model.

Robert N M Watson
Computer Laboratory
University of Cambridge