On Wed, Jul 14, 2010 at 12:32:26AM -0500, Nicolas Williams wrote:
> One possible improvement that comes to mind would be a private vforkx()
> flag to request that threads in the parent other than the one calling
> vforkx() not be stopped. The child would have to be extremely careful
> to not call malloc() or do anything that might disturb the state of the
> parent beyond the current stack frame, which is why such a flag would
> have to be private and undocumented. But this should not be considered
> until someone first shows that posix_spawn() performance is a problem
> and that the parent thread stop/resume overhead is the biggest ticket
> item.
It's significantly more complicated than that. You'd have to ensure
that there are no race conditions between the atfork handlers, rtld,
libc, and any application specific locking. The vfork manual is already
pretty clear that all bets are off should you use this in a
multi-threaded application:
The use of vfork() or vforkx() in multithreaded applica-
tions, however, is unsafe due to race conditions that can
cause the child process to become deadlocked and conse-
quently block both the child and parent process from execu-
tion indefinitely.
A solution that creates a new process without a call to fork is the best
idea I've heard so far. Unfortunately, as Bart has already observed,
it's a lot of work for a gain that has yet to be quantified.
-j
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
