Re: [Caml-list] Threads & Fork

[Oliver Bandel <oliver@first.in-berlin.de>]

On Tue, Nov 22, 2005 at 06:32:55PM +0100, Alexander S. Usov wrote:
> On Tuesday 22 November 2005 16:50, Oliver Bandel wrote:
> > On Tue, Nov 22, 2005 at 04:39:07PM +0100, Florian Weimer wrote:
> > > * Jonathan Bryant:
> > > > I'm confused as to why the attached code hangs.  My understanding of
> > > > Unix.fork () is that it completely clones the current process, which in
> > > > my understanding, clones the processes's threads as well.  Apparently,
> > > > though, that is not the case, because I can't join the thread in both
> > > > the parent and the child.
> > >
> > > I can't speak for the OCaml run-time, but POSIX fork only duplicates
> > > the current thread, so the new process is essentially single-threaded.
> >
> > I doubt that this is true.
> > Unix-fork() copies a complete process.
> > If the original has threads, the copy also have.
> > I don't think that POSIX handles this different to old Unix API.
> >
> > Unix-module should do the same as the C-call of fork(2).
> >
> > Threads are running inside a process, like any other
> > function. So all should be copied completely.
> >
> > But using POSIX-threads and Unix-API can yield to many problems,
> > for example POSIX threading signals and Unix-signals are clashing
> > together and the behaviour can be undefined...
> 
> [Option End]A process shall be created with a single thread. If a 
> multi-threaded process calls fork(), the new process shall contain a replica 
> of the calling thread and its entire address space, possibly including the 
> states of mutexes and other resources. Consequently, to avoid errors, the 
> child process may only execute async-signal-safe operations until such time 
> as one of the exec functions is called. [THR] [Option Start]  Fork handlers 
> may be established by means of the pthread_atfork() function in order to 
> maintain application invariants across fork() calls. [Option End]
> 
> (c) SUS v3

OK, I looked into my literature...

    "Pthreads specifies that only the thread calling fork exists in the child."
                       (David R. Butenhof: Programming with POSIX-Threads, p. 197)

OK, so I was wrong with my doubting... ;-)

But... the other threads' states in the child are the same as in the
parent.... and other things are also very.... strange.
Mutexes and other things are living inb the child, but
threads that possibly would work with them don't exist...
...there is no cleanup done...
...well.. so better don't use it this way.
So Butenhof said the same as you found in SUS v3 .... 

Ciao,
   Oliver