Hi Peter,
I'm glad to see you're getting into the Reactive code!
As a complement to Luke's answer:
I think readIVar is an exception to the usual guidelines below. The point
of the IVar type is that it can get written *at most once*, so any read will
yield the same value. It doesn't matter in this case whether the readMVar
computation is duplicated. It always has to yield the same result, namely
the only value that has been or will be written to the MVar, or bottom if no
value ever gets written. As Luke mentioned, the IVar interface does not
allow takeMVar to be called, except via readMVar, which replaces the value
after reading.
- Conal
2008/11/20 Peter Verswyvelen
When I was browsing the GHC documentation, I came across the following: If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. You have to be careful when writing and compiling modules that use unsafePerformIO:
- Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once. - Use the compiler flag -fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like test in the example below). - Make sure that the either you switch off let-floating, or that the call to unsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls to f. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.
Now in Reactive, in e.g. the internal IVar.hs module, I see
readIVar :: IVar a -> a readIVar (IVar v) = unsafePerformIO $ readMVar v
At first sight this function is not following all the rules described above. Could this cause problems?
Cheers, Peter
_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive