From owner-cvs-all@FreeBSD.ORG Wed Jun 18 08:16:41 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D58831065676; Wed, 18 Jun 2008 08:16:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 50A728FC1C; Wed, 18 Jun 2008 08:16:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BDFDB46B51; Wed, 18 Jun 2008 04:16:40 -0400 (EDT) Date: Wed, 18 Jun 2008 09:16:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Schultz In-Reply-To: <20080617170755.GA30958@zim.MIT.EDU> Message-ID: <20080618091320.F18654@fledge.watson.org> References: <200806170633.m5H6XMJH084600@repoman.freebsd.org> <20080617134828.GA30076@zim.MIT.EDU> <20080617140600.GE1176@hoeg.nl> <4857D508.8070907@FreeBSD.org> <20080617170755.GA30958@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Maxim Sobolev , src-committers@FreeBSD.ORG, Ed Schouten , cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG, David Xu 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 08:16:42 -0000 On Tue, 17 Jun 2008, David Schultz wrote: > On Tue, Jun 17, 2008, Maxim Sobolev wrote: >> Ed Schouten wrote: >>> * David Schultz 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