[MLton] switching to handler caught threads

[Matthew Fluet]

> So, it looks like we need two different behaviors when switching to
> threads.  For new threads created as above, we need to be in a
> critical section when starting the switch and after ending the switch
> and starting SML code.  For paused threads created by fromPrimitive,
> we need to *not* be in a critical section after ending the switch and
> returning to SML.  For paused threads created by Thread.switch, we
> could go either way, depending on whether or not we place a call to
> atomicEnd after the call to switchTo in atomicSwitch'.
>
> The easies fix I can think of is to have two variants of
> Prim.switchTo.  One will be used for all paused threads, and perform
> the canHandle--.  The other will be used for all new threads, and will
> let the thread being switched to do the canHandle--.
>
> Does that make sense?  This stuff is always very tricky.

I think so.  I see the real problem as not being able to prepend code onto
a Paused thread in a way that gets the prepended code to run in the right
place (that is, after the switch).

The thing I dislike about doing a canHandle-- in Prim.switchTo is that it
will mean duplicating the logic for atomicEnd in both the backend and the
runtime -- because we want to move to a situation where the signal handler
is immediately invoked when canHandle reaches 0 and a signal is pending.
That seems to suggest that Prim.switchTo might actually switch to the
signal handler.

It's all a little complicated in my mind.