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

[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

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

Peter