Date: Sat, 12 Dec 2009 13:38:48 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Nate Eldredge <nate@thatsmathematics.com> Cc: freebsd-hackers@freebsd.org, Linda Messerschmidt <linda.messerschmidt@gmail.com> Subject: Re: Superpages on amd64 FreeBSD 7.2-STABLE Message-ID: <alpine.BSF.2.00.0912121337320.61723@fledge.watson.org> In-Reply-To: <Pine.GSO.4.64.0912100729550.5432@zeno.ucsd.edu> References: <237c27100911260714x2fcb194ew1e6ce11e764efd08@mail.gmail.com> <200912090907.33433.jhb@freebsd.org> <20091210145052.GX20668@cicely7.cicely.de> <237c27100912100723u77c5dd2udbcd3732ed9ee6a@mail.gmail.com> <Pine.GSO.4.64.0912100729550.5432@zeno.ucsd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Dec 2009, Nate Eldredge wrote: > 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. Just as a note here: while we do posix_spawn(3) as a library function, Mac OS X does it as a system call. As a result, they can implement certain spawn flags that we can't, among others, the ability to have the newly created process/image be suspended before its first instruction executes. This would be very useful when debugging the runtime linker, among other things. On the other hand, it's quite a complex kernel code path... 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?alpine.BSF.2.00.0912121337320.61723>