Subj : Re: A pity that there is no forkall() which clones threads
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sun Mar 06 2005 03:36 pm

Marcin 'Qrczak' Kowalczyk wrote:

>
> 
> Maybe I should introduce something which says "when you want to
> interrupt me while I'm making this foreign call, send me SIGUSR1".

This would be the nicest way to do it; however, this is not portable to i.e.
windows...

Oh well but fork is not portable to windows too, AFAIK ...

> 
>> Add a function that foreign code can use to set the interruptible
>> flag for the current thread. The flag is always unset (i.e.
>> uninterruptible) on entry to a foreign function, and setting it only
>> lasts only until the code returns or next makes a call into the Kogut
>> runtime. (This ensures that there can be no problems with forgetting
>> to reset the flag or failing to do so because of a C++ exception.)
> 
> Hmm. An interesting idea. This would be specific to ForkProcess:
> "don't wait for me, I agree to be evaporated at fork".

That's right, but be carefull: the space between the flag setting in the
foreign api and the return to the VM (or the call to something inside the
VM) must be async-cancel-safe too. And that's a problem:

mutex_lock();
can_cancel_me = false;
mutex_unlock();

would not do as you can get cancelled before releasing the lock. An atomic
operation, or preventing cancellation right after the calls/returns (with
pthread_set_cancel_state), is in order.

> 
>> Note that foreign code only has to set the interruptible flag when it
>> does blocking I/O or a lengthy computation that does not call back
>> into the runtime.
> 
> If it calls back to the runtime, it must use a C function which among
> other things processes pending signals. This flag would be used before
> lengthy computations which don't cause effects on the world, only read
> its state, like getaddrinfo.
> 
> The implementation would be very ugly though. I'm not sure whether
> it's doable at all without rewriting the whole forking logic.
> 

It's doable, but it's actually quite ugly. IMHO, you should just say "if you
use FORK with the kogut VM being in MT, the state of the child is
undefined. Either stop every thread before calling fork() or call it before
starting threads".

Remember that the most important threading decisions, and it is probably
sensible to call "important" the forking decision, should be taken at
toplevel agent logic, i.e. by the programmer writing kogut programs...
Proably, taking care of this detail in place of the final kogut programmer
would cause her (in the sense, to your VM, and so to her) more troubles
than having this managed by herself.

Gian.

.