Glenn Fowler wrote: > On Mon, 30 Oct 2006 04:58:32 +0100 Roland Mainz wrote: > > Alan Coopersmith wrote: > > > Roland Mainz wrote: > > > > ... which raises the question whether ksh93 should (or could) use > > > > |posix_spawn()| instead of |vfork()| > > > > > > I had the same thought a couple of weeks ago, but then I plugged > > > "posix_spawn ksh93" into a google search and one of the top hits > > > was: > > > > > > package changes from 2002-12-21 to 2003-04-22 > > > ... ksh93 was modified to accept :% as equivalent to % and :# as > > > equivalent to > > > ... comp/spawnveg.c: call posix_spawn() if implemented comp/omitted.c: > > > add ... > > > www.research.att.com/~gsf/download/release.2003-04-22.2002-12-21.html > > > Ouch... sometimes it helps to read the changelogs... ;-/ > > ... however I checked it via "dbx" and it seems that at leaszt > > ast.ksh-2006-09-12 uses |vfork()| when executing an external command > > (like /usr/bin/ls) ... ;-( > > if you look close at the iffe test it says something like > "posix spawn works and is worth using" > part of the test checks to see if the native posix_spawn() > implementation uses fork() (there are some implementations that do) > needless to say, those implementations are deemed "not worth using" > when vfork() is available and works like vfork() should > > I don't know if this is the case for the system you built ksh on
On Solaris 11/B48/i386 with ast-ksh.2006-10-26 the "iffe" test says: -- snip -- iffe: test: posix_spawn exists and it works and its worth using ... no -- snip -- IMO should should be "yes" on Solaris for "correctness" reasons... ... however I am not sure whether |posix_spawn()| is faster than |vfork()| - the following stacktrace and http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/port/threads/spawn.c#271 reveal some interesting implementation details: -- snip -- (dbx) where =>[1] _vfork(0xffbfdb4c, 0xff28adc0, 0xffbfdb4c, 0x0, 0xff1701c0, 0x0), at 0xff23725c [2] _posix_spawn(0xffbfdb48, 0x28242, 0x0, 0xffbfdb4c, 0x280d8, 0x28104), at 0xff228db8 [3] spawnveg(0x28242, 0x280d8, 0x28104, 0x0, 0x280a1, 0x89a2c), at 0xff05e65c [4] _spawnveg(0x28242, 0x1, 0xff38f678, 0xff38c000, 0x0, 0x44848), at 0xff3477f0 [5] path_spawn(0xffffffff, 0x280d8, 0x28240, 0x3d, 0x3, 0x28242), at 0xff349778 [6] sh_ntfork(0xff38c000, 0x1, 0xff38f678, 0xff38f220, 0xff38c000, 0x0), at 0xff359a00 [7] sh_exec(0x280a8, 0x24, 0xff38f220, 0x232f0, 0x65ab0, 0xff0eac60), at 0xff3551a4 [8] exfile(0xff38f220, 0x280a8, 0x34, 0xff38f678, 0xff38f678, 0xff38c000), at 0xff318e60 [9] sh_main(0xff38f220, 0x319c8, 0xff38c000, 0xff38c000, 0xff38c000, 0xff38c000), at 0xff3183b0 -- snip -- Erm... why does |posix_spawn()| call |vfork()| in this case ? The vfork(2) manual page says this function call is depreciated... ---- Bye, Roland P.S.: It seems the idea with SHOPT_SPAWN was for /dev/null since this CPP symbol does something different... ;-( -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
