Andres Kroonmaa wrote:
> I've been trying to find out whether Solaris has changed its fork
> to more efficient. If it has then its no point in pursuing vfork,
> as so far all that I have found is warnings against using it and
> Solaris is notoriously slow to change such things. I'd bet it to
> be last one. ;/ Even Solaris man says don't use it, it will be
> eliminated in future.
The solaris fork is reasonably efficient. The only thing is that it (like on
all other OS:es by default) requires you to have sufficient swap space to fit
all concurrent copies of the process, even if this space isn't ever used. It
allocates the swap space "just in case" each process would want write to
every cloned data page. In case of fork+exec this is plain stupid, and bites
hard when a large process wants to spawn many copies of another smaller
program as you then quickly run out of swap space because all your swap has
been reserved (but not yet used).
> Thats probably OS dependant. Solaris claims to specifically deal
> with possible deadlock situation arising from signals during vfork.
The claims on signal support (or lack there of) for vfork is different from
system to system. The standard only says that if there is signal handles then
these have to comply with the same requirements as for the main program..
only modify a single pid_t variable used to keep the return value of vfork(),
call a function in the exec() family or _exit().
Regards
Henrik
Received on Wed Apr 03 2002 - 08:01:36 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:57 MST