[Haskell-cafe] ANN: atomic-modify-general

Tom Smeding x at tomsmeding.com
Fri Mar 10 09:09:53 UTC 2023


I'm not the person to ask :) Maybe someone else on the list can chip in 
here.

Another question if you don't mind (I'm learning here): you say below 
that in atomicModifyIORef2Native, you rely on heap object layout to 
unsafeCoerce between a pair and any object with an interesting value in 
the first field. But looking at the source [1], it seems you only do 
this for base < 4.13, i.e. GHC < 8.8.4. That's been a while.

Is it true that for GHCs since 8.8.4 you can just use a primop to do 
what you want directly, without the magic Generic stuff? If so, perhaps 
you can even drop the Generic constraints for high enough GHC versions 
(by extending the scope of the CPP slightly)? 8.6.5 is still popular, 
but simultaneously a whole bunch of applications don't care about GHCs 
<9 anymore.

- Tom

[1]: 
https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0/docs/src/Data.IORef.AtomicModify.Generic.html#atomicModifyIORef2Native

On 10/03/2023 09:45, David Feuer wrote:
> Whoops! Thanks for pointing that out. I'll fix it and push new docs. 
> There's not much magic in that part of the code itself; the nasty 
> magic is knowing that the first pointer in any record is in the same 
> position in its heap object as the first component of a pair. Speaking 
> of which, do you have any idea if it'll work for non-record types 
> whose constructors all have the same first field? I'm guessing yes, 
> but I haven't experimented yet.
>
> On Fri, Mar 10, 2023, 3:27 AM Tom Smeding <x at tomsmeding.com> wrote:
>
>     Hi David,
>
>     Fancy stuffs!
>
>     Wondering how much magic was going on in implementing this, I saw
>     that
>     atomicModifyIORef2Native misses the haddock marker '|' in the source;
>     thus your extensive doc comment doesn't show up on hackage.
>
>     Cheers,
>     Tom
>
>     On 10/03/2023 03:01, David Feuer wrote:
>     > I just put together a new package, atomic-modify-general, for
>     > generalizations of the `atomicModifyIORef` operation. In particular:
>     >
>     > 1. Versions that allow a result of an arbitrary type (not
>     necessarily
>     > a pair), where the caller passes in an extraction function.
>     These work
>     > with `Array` and `SmallArray` from `primitive` as well as `IORef`.
>     > 2. A version that works with record types (not just pairs) whose
>     first
>     > field is the new value to install in the `IORef`. This uses
>     > implementation details of the `atomicModifyMutVar#` primop as
>     well as
>     > GHC's heap object layout to achieve better performance.
>     >
>     > Please try it out and let me know how it goes, and what extras
>     you may want!
>     >
>     > Hackage:
>     https://hackage.haskell.org/package/atomic-modify-general-0.1.0.0
>     > _______________________________________________
>     > Haskell-Cafe mailing list
>     > To (un)subscribe, modify options or view archives go to:
>     > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     > Only members subscribed via the mailman list are allowed to post.
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     To (un)subscribe, modify options or view archives go to:
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>     Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20230310/83045769/attachment.html>


More information about the Haskell-Cafe mailing list