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

[Jörg F . Wittenberger]

On Sep 29 2011, 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.

True.

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
enable-initerupts).

(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!
>
> ABS
>
> - --
> Alaric Snell-Pym
> http://www.snell-pym.org.uk/alaric/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6EkCcACgkQRgz/WHNxCGoBNwCfS5syjjCVWFiyjcP0S6z/BFoB
> s6MAnjE+v+0Tf32+9bQ+X6wd6UgEA+pA
> =fjVS
> -----END PGP SIGNATURE