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