On Wed, Jul 14, 2010 at 01:12:37PM -0500, Nicolas Williams wrote: > On Wed, Jul 14, 2010 at 11:06:38AM -0700, johan...@opensolaris.org wrote: > > On Tue, Jul 13, 2010 at 06:41:32PM -0500, Nicolas Williams wrote: > > > As to your question, posix_spawn(2) wouldn't fork at all under the > > > covers: as a syscall it'd not have to. It'd create a new process as a > > > child of the parent, but it'd not use the parent's address space at all. > > > There'd still be some amount of locking to copy the file descriptor > > > table and so on, of course, but nothing quite like the copying or > > > borrowing of the parent's address space (almost certainly the most > > > expensive part of fork(2)/ vfork(2)). > > > > I'd like to see data for this assertion too. The code that's executed > > for vfork performs very few address space manipulations while borrowing > > the parent's address space. All it does today is clear and restore > > watched pages. Most processes don't have watchpoints on their pages. > > "Borrowing the parent's address space" means stopping all of the > parent's threads, at least for vfork() because that's what the > documented semantics of it are. I've explained this elsewhere in this > thread. I'm sorry you thought that I meant that vfork() does expensive > address space manipulations.
So back to Bart's point about the maintenance burden of two separate but nearly identical code paths. Without any data, this discussion is very silly. -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
