Proposal: Add atomic IORef operations to Data.IORef
Alexey Kuleshevich
alexey at kuleshevi.ch
Fri Jan 15 20:18:58 UTC 2021
Both of these functions are lazy with respect to the new value being written into the IORef, which is a horrible default for atomic operations. That is why atomicModifyIORef is a source of memory leaks and terrible performance, which is also why atomicModifyIORef' is almost always used instead.
So +1 from me on adding strict versions of these functions that force new value to whnf, but -1 for adding these lazy versions as they are currently defined in GHC.IORef
Alexey.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 15, 2021 11:05 PM, David Feuer <david.feuer at gmail.com> wrote:
> GHC.IORef currently exports
>
> atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b))
> atomicSwapIORef :: IORef a -> a -> IO a
>
> atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns
> both the old value in the IORef and the full result of applying the
> user-supplied function to that. This is a pretty thin wrapper around
> the newish atomicModifyMutVar2# primop, which has replaced the less
> powerful atomicModifyMutVar#.
>
> atomicSwapIORef atomically installs a user-supplied value in an IORef
> and returns the old value. It is currently implemented using
> atomicModifyIORef2, but it can and should be reimplemented using its
> own, more efficient primop.
>
> I propose to add both of these functions to Data.IORef.
>
> David
>
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
More information about the Libraries
mailing list