Blocking a task indefinitely in the RTS

[Phyx]

> 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/eef68dc3/attachment.html>