Re: [m-users.] Two more predicates for dealing wih threads

YAGNI!

I have not used Haskell in the years since I began my Mercury journey TBH!

> On 6 Nov 2023, at 10:29, Volker Wysk <[email protected]> wrote:
> 
> Am Montag, dem 06.11.2023 um 18:01 +1100 schrieb Peter Wang:
>> On Mon, 06 Nov 2023 05:23:03 +0100 Volker Wysk <[email protected]> wrote:
>>> Am Montag, dem 06.11.2023 um 14:28 +1300 schrieb Richard O'Keefe:
>>>> 
>>>> Surely a lighter-weight thread.channel is possible and desirable?
>>> 
>>> I don't know if it's possible, but 2N+4 semaphores sounds really heavy...
>>> 
>> 
>> thread.channel was "inspired" by Tackling the Awkward Squad
>> https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf
> 
> This looks interesting. (I also am a Haskell programmer).
> 
>> 
>> IIRC what makes thread.channel hard to implement another way is the
>> "duplicate" operation. I've never needed to duplicate a channel, though.
>> Also, comparing channel.take to readChan in the GHC implementation shows
>> that duplicated channels in Mercury never worked in the way they were
>> intended, as broadcast channels. (The bug was present in the code in the
>> original paper.)
>> https://github.com/ghc/ghc/blob/e451139f7a97d219ed8630b054d3a0875037aa0c/libraries/base/src/Control/Concurrent/Chan.hs#L110
>> 
>> If we dropped "duplicate", it should be possible to create a lighter
>> implementation of thread.channel. I still don't think it will be that
>> straightforward using semaphores (as opposed to condition variables,
>> which the Mercury standard library doesn't have).
> 
> Hmmm.. Perhaps this could be done? (But I don't need it right now.)
> 
> Cheers,
> Volker
> _______________________________________________
> users mailing list
> [email protected]
> https://lists.mercurylang.org/listinfo/users

_______________________________________________
users mailing list
[email protected]
https://lists.mercurylang.org/listinfo/users