I don't want spawn(2), I want posix_spawn(2). The last is more
powerful and would reduce the number of system calls, possibilities
for race conditions and execute faster than the bla(), bla(), bla(),
bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(),
bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(),
bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(),
bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(),
bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(), bla(),
vfork(), exec() applications and shells have to use today.
Olga
2010/7/12 Phil Harman<phil.har...@gmail.com>:
This was one of my pet peeves during my 20 years at Sun. The main reason I wanted spawn(2) was for
multithreaded apps needing to start new processes. The issue was that all LWPs need to be quiesced
before even a vfork(2), which meant that something as simple as just calling system(3) might stop
the world. The standard response from the gurus was ETOOHARD, followed by a good dose of FUD about
how fundamental fork/exec was to UNIX, and that we couldn't be sure a spawned process would be
exactly the same, "think of all the implicit inheritance". The proposed workaround was
always the same: "your multithreaded app should use a fork helper co-process to do its
spawning for it".
I salute you and wish you well!
On 12 Jul 2010, at 04:46, ольга крыжановская<olga.kryzhanov...@gmail.com>
wrote:
Perf team, has any one been interested in implementing posix_spawn()
as system call to improve performance? posix_spawn() is implemented as
sequence of vforkx and execve currently with many intermediate system
calls around it. From by looking at it and the kernel code of vforkx
and execve it might be beneficial to turn the whole thing into one
single system call.
Olga
--
, _ _ ,
{ \/`o;====- Olga Kryzhanovska -====;o`\/ }
.----'-/`-/ olga.kryzhanov...@gmail.com \-`\-'----.
`'-..-| / http://twitter.com/fleyta \ |-..-'`
/\/\ Solaris/BSD//C/C++ programmer /\/\
`--` `--`
_______________________________________________
perf-discuss mailing list
perf-disc...@opensolaris.org
