| In the meantime, I'm glad we have got a new function | atomicModifyIORef | which I for one will use, when it gets into GHC's regular release.
Just before this gets out of the door... any chance of calling it
modifyIORef
and documenting that it's atomic? Sometimes names can get too long!
Not a big deal though.
It has a different type: atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b modifyIORef :: IORef a -> (a -> a) -> IO () we could either 1. specify that modifyIORef is also atomic. That is useful, because using an atomic version of modifyIORef would be faster than using atomicModifyIORef if you don't need a return value. However, the atomic version of modifyIORef would be slower than the non-atomic version. 2. add atomicModifyIORef_, with the same signature as modifyIORef. I don't really have strong feelings either way, but I think I'd be slightly inclined towards (2) if anything. Cheers, Simon
On Tue, Oct 22, 2002 at 10:37:17AM +0100, Simon Marlow wrote:
| In the meantime, I'm glad we have got a new function | atomicModifyIORef | which I for one will use, when it gets into GHC's regular release.
Just before this gets out of the door... any chance of calling it
modifyIORef
and documenting that it's atomic? Sometimes names can get too long!
Not a big deal though.
It has a different type:
atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b modifyIORef :: IORef a -> (a -> a) -> IO ()
It would break backwards compatability, but modifyIORef_ :: IORef a -> (a -> IO a) -> IO () modifyIORef :: IORef a -> (a -> IO (a, b)) -> IO b (both specified atomic) would be consistent with the MVar names.
participants (2)
-
Ross Paterson -
Simon Marlow