My concern is not threading, not yet, until ksh93's multi thread support lands in Solaris. My concern is that fork and exec do double work or fork does jobs which are then un done by exec again, but I can only speak for the BSD implementation of fork and exec, not Solaris. A posix_spawn system call would eliminate much of this madness.
Olga On Wed, Jul 14, 2010 at 1:41 AM, Nicolas Williams <nicolas.willi...@oracle.com> wrote: > On Tue, Jul 13, 2010 at 04:24:35PM -0700, johan...@opensolaris.org wrote: >> On Tue, Jul 13, 2010 at 01:30:36PM -0500, Nicolas Williams wrote: >> > On Mon, Jul 12, 2010 at 02:26:45PM -0700, Bart Smaalders wrote: >> > > The overhead cost of a system call is about the same as a L3 cache miss: >> > > of order 150 ns. Given the general expense in creating a new process by >> > > any means, this would not be my first place to look for performance >> > > wins. >> > >> > But the overhead of vfork() is probably much higher when the parent has >> > multiple threads, since they must all get stopped first, and then later >> > they must all be made runnable again. Java, Firefox, Thunderbird, all >> > come to mind as programs that might benefit from a native posix_spawn(2), >> > but first we need to see them using posix_spawn(3C). >> >> Since you're the third person to assert that the overhead of stopping >> lwps is prohibitive, would you please explain how it's possible to >> safely fork a process if all of the lwps are still running? > > I didn't say prohibitive, but clearly having to stop N threads, some or > all of which are possibly running on other CPUs (xcalls) is more > expensive than not having to at all. Whether that's prohibitive, or > whether there exist apps for which that even a small cost of > stopping/restarting the parent would add up to a lot of CPU time, I > don't know and leave to others to answer. > > 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)). > >> The vfork[x](2) code that's in posix_spawn right now already sets the >> isfork1 bit, which tells cfork to be less restrictive about just where >> exactly the process is stopped. > > Surely all threads must be stopped by vfork() (the manpage says "[t]he > parent process is suspended while the child is using its resources"). > Regardless of where the stopping points might be, surely a solution that > doesn't require stopping the parent's threads at all would be faster. > >> Correctness > performance. > > Indeed. But please tell us where I proposed anything that might > comprimise our ability to be correct. You seem to have missed the point > that, if implemented as a system call, posix_spawn(2) can avoid > altogether the need to "fork" in the traditional sense. > > Nico > -- > _______________________________________________ > on-discuss mailing list > on-disc...@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/on-discuss > -- , _ _ , { \/`o;====- Olga Kryzhanovska -====;o`\/ } .----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----. `'-..-| / http://twitter.com/fleyta \ |-..-'` /\/\ Solaris/BSD//C/C++ programmer /\/\ `--` `--` _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
