>>>Erm... why does |posix_spawn()| call |vfork()| in this case ? It calls a special libc-internal version of vfork() that can ONLY be called from inside libc.
> The >>>vfork(2) manual page says this function call is depreciated... >> >>This is in the manual page since vfork() exists.... No. It only says this starting with Solaris 10. >>Vfork() is the only way to implement posix_spawn() the way you like >>(efficient). No. posix_spawn() can also be made into a syscall on its own (which is not the way it is done in Solaris right now). > If you look at the internal implementation of posix_spawn(), you'll > see that it does things to avoid the pitfalls of vfork and the dynamic > linker. Right. > Additionally, if something in the system were to change in the future > such that vfork() became more of a problem, posix_spawn() (as a safe > alternative) would get those fixes. Programs calling vfork() might > not. vfork() is a problem already. Calling vfork() is NOT safe now and will not be safe in the future. > The man page doesn't just say that it's deprecated. It says: > > The vfork() function is deprecated. Its sole legitimate use > as a prelude to an immediate call to a function from the > exec family can be achieved safely by posix_spawn(3C) or > posix_spawnp(3C). > > The only legitimate thing you can do with it is to call exec right > away, and if you're going to do that, then the spawn function is > simpler and better. No. Even calling exec() right after calling vfork() is unsafe. BTW, all this is described in my paper: http://developers.sun.com/solaris/articles/subprocess/subprocess.html#impl -Greg
