Date: Tue, 17 Jun 2008 13:07:55 -0400 From: David Schultz <das@FreeBSD.ORG> To: Maxim Sobolev <sobomax@FreeBSD.ORG> Cc: Ed Schouten <ed@80386.nl>, src-committers@FreeBSD.ORG, David Xu <davidxu@FreeBSD.ORG>, cvs-all@FreeBSD.ORG, cvs-src@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: <20080617170755.GA30958@zim.MIT.EDU> In-Reply-To: <4857D508.8070907@FreeBSD.org> References: <200806170633.m5H6XMJH084600@repoman.freebsd.org> <20080617134828.GA30076@zim.MIT.EDU> <20080617140600.GE1176@hoeg.nl> <4857D508.8070907@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080617170755.GA30958>