[ksh93-integration-discuss] Shouldksh93/libshelluse|posix_spawn()| instead of |vfork()| ?

[Greg Nakhimovsky]

>>>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