George Russell <[EMAIL PROTECTED]> writes:
> OK, the point is to make programs more portable from NHC to other
> systems. (Perhaps you would rather lock them in? 8-) If I write, say,
> Alastair Reid's newObject and killObject in NHC using IORefs, then this
> will work fine in NHC, but may mysteriously go wrong when someone ports
> them to GHC and calls newObject and killObject simultaneously.
Yes, I agree that this is a problem. A naive programmer could try an
incorrect approach to mutating shared state in a Haskell finaliser,
and believe that it is correct and portable, simply because it happens
to work in nhc98. It would be nice to be able to lessen the chances
of this happening by providing the proper primitives for shared access.
> For example
> another mutable variable we could have would be a PVar which is always
> full and has functions
>
> newPVar :: a -> IO (PVar a)
> updatePVar :: PVar a -> (a -> a) -> IO a
I was musing that a single-threaded system might be able to provide
just a restricted set of atomic operations on MVars, say, something
like newMVar + withMVar + modifyMVar, which might be enough to
guarantee correct locking whilst excluding deadlock.
But your suggestion of a different synchronisation variable type with
more limited capabilities is probably better than trying to define
the precise restrictions on MVars.
I'll need to think some more about the details of PVars, but my first
reaction is that they would very easy to implement. However, I fear it
may be no good persuading me of their value if you cannot also persuade
the other implementations to adopt them, so I'd like to hear what Hugs
and ghc people have to say, especially whether they would also solve
the problems with mutable shared state raised by Alastair.
Regards,
Malcolm
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
