Re: [Chicken-users] remove enable/disable interrupt flag

[Alan Post]

On Thu, Sep 29, 2011 at 04:35:04PM +0100, Alaric Snell-Pym wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 09/29/2011 04:25 PM, Jörg F. Wittenberger wrote:
> 
> >> POSIX says that fork needs to produce only a single surviving POSIX
> >> thread in the child. Perhaps Chicken fork needs to do the same with
> >> Chicken threads.
> >
> > Alaric, that's exactly the effect and reason why I'm using this
> > disable-interrupts/enable-interrupts around fork: to make sure
> > there is only this one Chicken-threads running in the child.
> > With interrupts disabled there is no scheduling in chicken.
> > (At least not until you run into a thread-yield! anyway.)
> >
> > And therefore I'd really recommend to keep it in the runtime.
> 
> I think a better mechanism would be a way to abort all threads but the
> current one, triggered after the fork in the child, with no interrupts
> until the thread murder is complete.
> 
> If you just go off and exec after the fork it'd be better to
> uninterruptably vfork-then-exec, but we have procedures to do that already!
> 
> Aborting all threads but the one that asked for the fork also gives one
> the opportunity to inform them of this fact, should any of them leave
> useful data structures in incosistent states with locks held. There's
> something to be said for requesting permission to fork from all threads
> before doing so, so they can make sure they finish any operations on
> shared state in the parent, but that'll be complex, and a potential
> performance bottleneck, so probably not worth it!
> 
> ABS
> 

In posix threads, this is what pthread_atfork() is for--to clean up
resources in the process of joining threads across a fork.

The way Chicken is currently implemented, any signal that arrives
during this time is discarded, which also makes me unhappy with this
situation.  A lot of blood and tears were spilled over signal
handling on Unix to get to reliable signal delivery.  I don't think
Chicken should implement unreliable signal delivery on top of a
reliable mechanism.

It seems that the thread-like nature of signal handling and the
thread-like nature of threading have been intermixed in the
scheduler, and this particular feature is at cross-purposes.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du