Subj : Re: A pity that there is no forkall() which clones threads
To   : comp.programming.threads
From : roger.faulkner
Date : Sun Mar 06 2005 08:52 pm


Casper H.S. Dik wrote:
> Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> writes:
>
> >It's not enough to standarize forkall, it would have to be actually
> >implemented. Are there systems which provide it? Then fork/thread
> >interaction would be better at least on these systems.
>
> Solaris 10 provides it; earlier versions of Solaris provide fork()
> which is really forkall() [at least if you link with the non
> pthread thread library]
>
> Casper

But be warned.
There is a reason why Posix decided against forkall().
It is dangerous.

The child inherits all of the parent's open files, including
the file (seek) offsets.  On return from forkall() in both
parent and child, whatever threads were doing read()s or write()s
will continue doing those read()s or write()s.  Since the file
offsets are inherited (as in dup() of file descriptors), the
parent and child threads will be modifying each other's file
offsets and generally causing damage to each other's data.

You'd better have a sure-fire way of controlling access by every
thread to every resource that is inherited by the child from the
parent before trying to use forkall().

Roger Faulkner
Sun Microsystems

.