> Maybe that should be considered a false positive (bug) for the deadlock checker? Just because the Haskell runtime has a single thread, that doesn't imply the whole program is necessarily single-threaded (in the presence of foreign things). I'd think this is a legitimate use case for MVars.

Perhaps, I can see it both ways really :(. The papers and docs for MVars put a strong emphasis on this deadlock guarantee (though I've really only skimmed the paper), taking foreign calls into consideration does somewhat weaken this of course. I do agree with you that this wasn't the behavior I expected from MVars and STMs, particularly because they are such low level building blocks, for instance QSem is constructed with MVar, the docs make no mention of this but I suspect QSem and the rest all don't do what you'd expect on the non-threaded RTS.

I did try removing this check to see, but it really didn't like that. It caused GC to be triggered over and over again as the RTS tried desperately to find something to do, doesn't seem to consider "do nothing" as a valid state.

On Tue, Jan 8, 2019 at 6:59 AM Phil Ruffwind <rf@rufflewind.com> wrote:

Okay, I skimmed rts/Schedule.c and now see the problem you mentioned :(

> 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.

Maybe that should be considered a false positive (bug) for the deadlock checker? Just because the Haskell runtime has a single thread, that doesn't imply the whole program is necessarily single-threaded (in the presence of foreign things). I'd think this is a legitimate use case for MVars.