This would make MonadFix's implementation much nicer, I think :) On Fri, Jun 29, 2018 at 9:14 AM, Oleg Grenrus <oleg.gren...@iki.fi> wrote:
> I have wanted something like that! Also similiar STM TQVar would be nice > to have. For example `async` uses TMVar where the value is written only > once. if once filled the QVar cannot be empty is useful property. > > For STM variant, I'd actually like to have > > putTQVar' :: QTVar a -> a -> STM (TVar a) > > i.e. giving me back a `TVar a`, for which I now the value is already > there (i.e. reading won't block). Not sure what the would be such for > IO, IORef doesn't feel right. > > - Oleg > > On 29.06.2018 08:28, David Feuer wrote: > > IVars (write-once variables) can be useful for various purposes. In > Haskell, they can be implemented using MVars. But MVars are not the > lightest things in the world. I'm wondering if it might pay to implement > something much lighter primitively. Here's a sketch of some things I'll > tentatively call QVars. > > > > A QVar has two fields: a value (possibly null) and a stack (no need for > a queue) of waiting threads. > > > > newEmptyQVar: Create a QVar with a null value and an empty queue. > > > > tryReadQVar: Just look at the value. > > > > readQVar: Check if the value is null (simple memory read). If not, use > it. If so, push yourself onto the waiting stack (CAS loop). The code that > will run when you're awakened will try to awaken the next thread if there > is one (CAS loop). > > > > putQVar: Install a new value and get the old one (exchange). If the old > value was null, mark the QVar dirty. Awaken the first thread if there is > one (CAS loop). Return the old value if it was non-null (this can be used > in library code to make duplicate writes, or non-equal duplicate writes, an > error). > > > > I think we'd probably also want atomic modification operations, but I > haven't figured out which ones yet. > > > > Implementation differences from MVars: > > > > * We have two fields instead of three (because we can get away with a > stack instead of a queue). > > > > * We never need to lock the QVar closure. MVars do: they can change > freely between empty and full, so it's necessary to coordinate between > value and queue modifications. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs