On Tue, 17 Jun 2008, David Schultz wrote:
On Tue, Jun 17, 2008, 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?
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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
