I have simply copy pasted the code you provided. Note that my actual code code doesn't pass anything to a foreign interface. It stores everything in a Haskell mutable object.
The RTS on completion of actions simply schedules a task which inspects this objects and wakes up as many blocked tasks as possible.
>
Strange, how could the scheduler assume a deadlock if the MVar could be
called from a closure that is still alive? Can you show the code that
you're testing?
Because as far as I can tell, it doesn't care. When it comes to MVars and STMs the scheduler assumes a deadlock when all tasks on all capabilities are blocked.
For the threaded runtime it has an early exit condition from this code in the case where there has been any activity in a complete timeslice or when you're blocked on
specific calls such as I/O.
On the non-threaded runtime the timeslice case doesn't apply and you only have one capability, it will force a GC to try to revive some tasks, and if at the end of
this the tasks are still blocked it will release one in order to attempt to proceed. In short, as far as I can tell I don't think it considers reach-ability at all, not for MVars.
This is why things e.g. doing a takeMVar will also process pending puts etc, so that if you actually enter a blocked state, you know you had no other choice.