Blocking a task indefinitely in the RTS

Carter Schonwald carter.schonwald at gmail.com
Tue Jan 8 18:23:55 UTC 2019


What’s the underlying problem you’re trying to model?

On Tue, Jan 8, 2019 at 3:56 AM Phyx <lonetiger at gmail.com> wrote:

> > Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the
> RTS could use a new intrinsic for blocking on foreign state
>
> Yeah, that's what I was/am currently working on, "IOPort" has much of the
> same property of MVar but doesn't have this deadlock guarantee and only
> supports a single put/take at a time.
> But debugging CMM is... not fun :( so I was wondering if I was just
> missing something with the existing mechanisms.
>
>
> On Tue, Jan 8, 2019 at 8:23 AM Phil Ruffwind <rf at rufflewind.com> wrote:
>
>> > 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.
>>
>> Oh, I see :(  I guess it's not that easy of a fix then.  Perhaps the RTS
>> could use a new intrinsic for blocking on foreign state.
>>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190108/bede8ed2/attachment.html>


More information about the ghc-devs mailing list