The current `modifyMVar`, though exception safe, is not
atomic in the
same way that the proposed `atomicModifyMVar` would be. Unless I
misunderstand, during the execution of `modifyMVar`'s second
argument, the
mvar is empty and could be filled by some other thread. With
Simon Marlow wrote:
Simon Marlow wrote:
[...] There was this, from Dean Herrington:
http://haskell.cs.yale.edu/pipermail/ffi/2002-October/000940.html
I don't have any strong feelings (I rarely do, where names are
concerned).
I would be happy with his proposal. We can
I wrote:
One might reasonably worry about the proliferation of MVar manipulation
functions. I think it's useful to realize that there are semantically only
four primitives in the proposed extended interface: `newEmptyMVar`,
`atomicModifyMVar`, `atomicTryModifyMVar`, and `addMVarFinalizer`.
