[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] remove enable/disable interrupt flag
Date: 29 Sep 2011 18:38:34 +0200

On Sep 29 2011, Alaric Snell-Pym wrote:

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.


Though I view doing this as a higher level, complete solution.

And it depends on the ability to disable interrupts.  Given that we
can, we are free to choose an option:

A) Forget about all other chicken threads and just exec the code.
This is the vfork-then-exec case.  Chances are that this is, what
the doctor ordered in most cases.  (As it is in mine.)

B) Kill the threads and re-enable chicken's scheduler (aka

(B) might need some more considerations.  I'm not sure how this could
be mapped to srfi-18.  I'll abstain from guess work here.

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!


- --
Alaric Snell-Pym
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]