> [snip] How sad. It's an unfortunate hole in the specification and I
> hope someone will come up with a way of fixing it someday.
I don't think it'll happen until preemptive concurrency is more widely
implemented.
> In the meantime, I'm glad we have got a new function
> atomicModifyIORef which
| 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
> Do we still have atomicModifyIORef?
>
> I don't know that there's that much point now that Haskell finalizers
> are gone. I don't have a strong objection (esp. since it seems every
> implementation now has it) but it doesn't seem so necessary now.
It ought to be significantly faster than usin
> | 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 na
> 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!
There's two reasons you might use the function: convenience and atomicity.
I can easily imagine someone modifying a program, thinking
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
> >
> > 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
On Tue, Oct 22, 2002 at 12:56:52PM +0100, Simon Marlow wrote:
> Did you really mean those types, and not the types I quoted? That
> implies unsafeInterleaveIO if they have to be atomic.
Sorry, I meant the types you quoted. So the analogy isn't that strong.
___
Simon Peyton-Jones 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
Simon Marlow wrote:
>
> > Do we still have atomicModifyIORef?
> >
> > I don't know that there's that much point now that Haskell finalizers
> > are gone. I don't have a strong objection (esp. since it seems every
> > implementation now has it) but it doesn't seem so necessary now.
>
> It ought t
George Russell wrote:
> Simon Peyton-Jones 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
> >
> >
Dean Herington wrote (snipped)
> Here's the scheme I would
> prefer for the "modify" subset of these functions. Existing functions are
> labeled "(e)", proposed functions "(p)". "(*)" indicates an existing function
> with a different interface.
>
> (e) modifyMVar :: MVar a -> (a -> IO (a, b))
12 matches
Mail list logo
