I know that in the case of the prefetch operations they need to be treated like writes so that other operations don't get reordered before / after them.
For Mvars, concurrency probably comes into play. Or at least, before we did a readMvar primop it was made out of a take and put, so even through the read prim doesn't write and doesn't block other readers, we still want to treat it's ordering as through it has a write like side effect (Edward yang can probably better opine than I on that one ) On Fri, Mar 10, 2017 at 5:17 PM David Feuer <[email protected]> wrote: > Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says > > > A primop "has_side_effects" if it has some *write* effect, visible > > elsewhere > > > > - writing to the world (I/O) > > - writing to a mutable data structure (writeIORef) > > - throwing a synchronous Haskell exception > > > > [...] > > > > * NB3: *Read* effects (like reading an IORef) don't count here, > > > > because it doesn't matter if we don't do them, or do them more than > > once. *Sequencing* is maintained by the data dependency of the state > > token. > > But this does not actually seem to match what goes on in primops.txt.pp. > The > following, among many other seemingly read-only operations, have > has_side_effects = True: > > readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#, > unsafeThawArray#, tryReadMVar#, deRefWeak# > > So what's the correct story? Do we want to change the note, or change the > reality? The reason I happen to be looking at this is that I think the > current > arrangement allows us to define unsafeInterleaveIO in a particularly simple > fashion: > > unsafeInterleaveIO = pure . unsafePerformIO > > but that's only safe as long as the interleaved IO won't float out and get > performed before it's forced by normal IO. > > But the unsafeInterleaveIO story seems much less important, in the grand > scheme of things, than making everything else run fast. If indeed it's > otherwise safe to mark these read-only ops has_side_effects=False, then I > imagine we probably should do that. > > David Feuer > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
