Re: [m-users.] Two more predicates for dealing wih threads
Peter Wang <[email protected]> Mon, 6 Nov 2023 18:01:37 +1100
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <[email protected]> |
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 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 _______________________________________________ users mailing list [email protected] https://lists.mercurylang.org/listinfo/users