Interrupt interruptible foreign calls on HS exit

Edward Z. Yang ezyang at mit.edu
Wed Jul 30 22:57:28 UTC 2014


Recalling when I implemented this functionality, I think not
interrupting threads in the exit sequence was just an oversight,
and I think we could implement it.  Seems reasonable to me.

Edward

Excerpts from Andreas Voellmy's message of 2014-07-30 23:49:24 +0100:
> Hi GHCers,
> 
> I've been looking into issue #9284, which boils down to getting certain
> foreign calls issued by HS threads to finish (i.e. return) in the exit
> sequence of forkProcess.
> 
> There are several options for solving the particular problem in #9284; one
> option is to issue the particular foreign calls causing that issue as
> "interruptible" and then have the exit sequence interrupt interruptible
> foreign calls.
> 
> The exit sequence, starting from hs_exit(), goes through hs_exit_(),
> exitScheduler(), scheduleDoGC(), deleteAllThreads(), and then
> deleteThread(), where deleteThread is this:
> 
> static void
> deleteThread (Capability *cap STG_UNUSED, StgTSO *tso)
> {
>     // NOTE: must only be called on a TSO that we have exclusive
>     // access to, because we will call throwToSingleThreaded() below.
>     // The TSO must be on the run queue of the Capability we own, or
>     // we must own all Capabilities.
>   if (tso->why_blocked != BlockedOnCCall &&
> tso->why_blocked != BlockedOnCCall_Interruptible) {
>         throwToSingleThreaded(tso->cap,tso,NULL);
>     }
> }
> 
> So it looks like interruptible foreign calls are not interrupted in the
> exit sequence.
> 
> Is there a good reason why we have this behavior? Could we change it to
> interrupt TSO's with why_blocked == BlockedOnCCall_Interruptible in the
> exit sequence?
> 
> Thanks,
> Andi
> 
> P.S. It looks like this was introduced in commit
> 83d563cb9ede0ba792836e529b1e2929db926355.


More information about the ghc-devs mailing list