Date: Thu, 10 Dec 2009 07:42:53 -0800 (PST) From: Nate Eldredge <nate@thatsmathematics.com> To: Linda Messerschmidt <linda.messerschmidt@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE Message-ID: <Pine.GSO.4.64.0912100729550.5432@zeno.ucsd.edu> In-Reply-To: <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Dec 2009, Linda Messerschmidt wrote: > Also... > > On Thu, Dec 10, 2009 at 9:50 AM, Bernd Walter <ticso@cicely7.cicely.de> wrote: >> I use fork myself, because it is easier sometimes, but people writing >> big programms such as squid should know better. >> If squid doesn't use vfork they likely have a reason. > > Actually they are probably going to switch to vfork(). They were > previously not using it because they thought there was some ambiguity > about whether it was going to be around long term. Well, the worst that would likely happen to vfork() is it would become an alias of fork(), and you'd be back to where you are now (or better if fork() were fixed in the meantime). I'd be more worried about the mysterious bugs which it's so easy to introduce with vfork() if you do anything at all nontrivial before exec() and accidentally touch the parent's memory. What about using posix_spawn(3)? This is implemented in terms of vfork(), so you'll gain the same performance advantages, but it avoids many of vfork's pitfalls. Also, since it's a POSIX standard function, you needn't worry that it will go away or change its semantics someday. > I actually am not a huge fan of vfork() since it stalls the parent > process until the child exec()'s. If you're doing so much work between vfork() and exec() that this delay is significant, then I would think you're really abusing vfork(). > To me, this case actually highlights why that's an issue. If the > explanation is that stuff is happening in the parent process between > fork() and the child's exec() causes the fragmentation, that's stuff > that would be deferred in a vfork() regime, with unknown potential > consequences. (At a minimum, decreased performance.) Not necessarily. In the fork() case, presumably copy-on-write is to blame for the fragmentation. In the vfork() case, there's no copy at all. -- Nate Eldredge nate@thatsmathematics.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0912100729550.5432>