From owner-freebsd-current@FreeBSD.ORG Fri Nov 28 04:29:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7ACE16A4CE for ; Fri, 28 Nov 2003 04:29:37 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E2F143FE5 for ; Fri, 28 Nov 2003 04:29:34 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjun.dialup.mindspring.com ([165.247.207.215] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1APhjT-0005SH-00; Fri, 28 Nov 2003 04:28:24 -0800 Message-ID: <3FC73F2F.47E7D488@mindspring.com> Date: Fri, 28 Nov 2003 04:27:27 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm References: <20031127190413.6E8152A8FC@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43e8db1f80df87b8432eecaf7950c20ba387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c cc: current@freebsd.org Subject: Re: fork speed vs /bin/sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2003 12:29:38 -0000 Peter Wemm wrote: > What this shows is that vfork() is 3 times faster than fork() on static > binaries, and 9 times faster on dynamic binaries. If people are > worried about a 40% slowdown, then perhaps they'd like to investigate > a speedup that works no matter whether its static or dynamic? There is > a reason that popen(3) uses vfork(). /bin/sh should too, regardless of > whether its dynamic or static. csh/tcsh already uses vfork() for the > same reason. I'm a big fan of vfork(); the on problem I have with the use of it is that people tend to treat it as "a faster fork()", when it definitely is not. The utility of vfork() is limited to the list of allowed system calls, which are _exit() and execve(); all other usage is undefined -- specifically, you cannot control things like whether it's the parent or the child that gets effected by calls like setsid(), setpgrp(), etc.. The other place that vfork() really sucks is in applications like "screen" or other applications that have multiple children and act as mux'es for them: during the vfork() to spawn off a new child from the parent, the parent is stalled, and this in turn stalls all the children, as well. The vfork() system call is a good thing, particularly compared to the fork() system call, IFF it's used appropriately. For the most part, FreeBSD should consider creating a posix_spawn() system call, instead, for most uses to which people put either the fork() or vfork() system calls today. -- Terry