Subj : A pity that there is no forkall() which clones threads
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Sat Mar 05 2005 01:17 pm

My language Kogut has three variants of fork:

  * ForkProcess - other threads are stopped at a point where signals
    are unblocked; the process is forked; in the child process threads
    are canceled, and in the parent they are resumed
    (the safest default)

  * ForkProcessCloneThreads - all threads continue running in both
    processes
    (the simplest to describe semantics)

  * ForkProcessKillThreads - other threads are killed immediately with
    no cleanup
    (used before ExecProgram)

Meanwhile I added support for using pthreads for certain background
computations and for ensuring that callbacks from C run in their own
pthreads, based on the design described in a paper by Simon Marlow,
Simon Peyton Jones, and Wolfgang Thaller "Extending the Haskell
Foreign Function Interface with Concurrency".

A Kogut thread can be bound to an OS thread or unbound; conversely,
an OS thread can be bound to a Kogut thread or be one of worker
threads for executing unbound Kogut threads. The main thread and
threads which currently run callbacks are bound.

This design allows to create thousands of threads, doesn't require the
runtime and GC to be reentrant which would complicate and slow down it
too much, and at the same time those threads which must be run in
separate pthreads do so and there is no problem with concurrent
callbacks returning out of order on the same system stack.

Since it's impossible to fork a process together with other pthreads,
in the child process after ForkProcess and ForkProcessCloneThreads
all threads other than the one doing the fork become unbound.
If such orphaned thread returns from a callback, or if it was
executing foreign code at the time of the fork, it is killed as with
ForkProcessKillThreads, because the code it was supposed to return to
was executing in another pthread which doesn't exist here.

If there was forkall which clones pthreads, then ForkProcess and
ForkProcessCloneThreads would use it and with ForkProcess they will
run the cleanup into completion instead of being killed when they
return from a callback. ForkProcessKillThreads would continue to use
fork which causes pthreads to evaporate.

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.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

.