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

[Volker Wysk]

Am Montag, dem 06.11.2023 um 18:01 +1100 schrieb Peter Wang:
> On Mon, 06 Nov 2023 05:23:03 +0100 Volker Wysk <post at volker-wysk.de> 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