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