Date: Wed, 18 Jun 2008 09:16:40 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: David Schultz <das@FreeBSD.ORG> Cc: Maxim Sobolev <sobomax@FreeBSD.ORG>, src-committers@FreeBSD.ORG, Ed Schouten <ed@80386.nl>, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG, David Xu <davidxu@FreeBSD.ORG> Subject: Re: cvs commit: src/include Makefile spawn.h unistd.h src/lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c posix_spawn.c Message-ID: <20080618091320.F18654@fledge.watson.org> In-Reply-To: <20080617170755.GA30958@zim.MIT.EDU> References: <200806170633.m5H6XMJH084600@repoman.freebsd.org> <20080617134828.GA30076@zim.MIT.EDU> <20080617140600.GE1176@hoeg.nl> <4857D508.8070907@FreeBSD.org> <20080617170755.GA30958@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 17 Jun 2008, David Schultz wrote: > On Tue, Jun 17, 2008, Maxim Sobolev wrote: >> Ed Schouten wrote: >>> * David Schultz <das@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080618091320.F18654>