<div dir="ltr"><div>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.</div><div>The RTS on completion of actions simply schedules a task which inspects this objects and wakes up as many blocked tasks as possible.</div><div><br></div><div>> 
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?</div><div><br></div><div>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.</div><div>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</div><div>specific calls such as I/O.<br></div><div><br></div><div>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</div><div>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.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 11:24 PM Phil Ruffwind <<a href="mailto:rf@rufflewind.com">rf@rufflewind.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?  <br>
<br>
On Mon, Jan 7, 2019, at 14:09, Phyx wrote:<br>
> Hi Phil,<br>
> <br>
> Thanks for the reply, however that just gives me a forced deadlock removal<br>
> as before.<br>
> <br>
> new bound thread (1)<br>
> cap 0: schedule()<br>
> cap 0: running thread 1 (ThreadRunGHC)<br>
> cap 0: thread 1 stopped (blocked on an MVar)<br>
>         thread    1 @ 0000000003205388 is blocked on an MVar @<br>
> 00000000032040c8 (TSO_DIRTY)<br>
> deadlocked, forcing major GC...<br>
> all threads:<br>
> threads on capability 0:<br>
> other threads:<br>
>         thread    1 @ 0000000003205388 is blocked on an MVar @<br>
> 00000000032040c8 (TSO_DIRTY)<br>
> cap 0: starting GC<br>
> <br>
> I don't believe any solution involving MVars will work for the non-threaded<br>
> RTS. Though I'd love to be wrong here...<br>
> <br>
> Regards,<br>
> Tamar<br>
</blockquote></div>