johan...@opensolaris.org wrote: > 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.
Plus, the original poster was apparently mostly concerned about ksh93's performance, and making the heavy MT case work faster won't help that application a bit, because ksh93 isn't making use of threads. I think having the original poster come up with a test case of interest (something that runs significantly faster on "all other platforms") and then gathering basic data on that test case (where does a profiler say the system is spending its time?) would be a much better plan then speculating wildly on which magic new system call will make everything run better. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ on-discuss mailing list on-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/on-discuss
