[Haskell-cafe] What unsafeInterleaveIO is unsafe

[Jonathan Cast]

On Tue, 2009-03-17 at 12:59 +0100, Ketil Malde wrote:
> Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:
> 
> >> [..] I have a sneaking suspicion [exceptions] actually *is* `unsafe'.  Or, at
> >> least, incapable of being given a compositional, continuous semantics.
> 
> > Basically if we can only catch exceptions in IO then it doesn't matter,
> > it's just a little extra non-determinism and IO has plenty of that
> > already.
> 
> Couldn't you just substitute "catch exceptions" with "unsafePerformIO"
> here, and make the same argument?

This puzzled me, until I realized you meant `unsafeInterleaveIO'.
That's pretty much the argument that is made for unsafeInterleaveIO.

> Similarly, can't you emulate unsafePerformIO with concurrency?

Assuming you mean unsafeInterleaveIO, not quite.  GHC's scheduler is
fair, so you are guaranteed after

    forkIO $ a

that a's side effects will happen eventually.  On the other hand, after

    unsafeInterleaveIO $ a

you have basically no guarantee the RTS will ever get around to
scheduling a.  (In fact, if you write it just like that in a do block,
rather than saying

    x <- unsafeInterleaveIO $ a

you are pretty much guaranteed that the RTS won't ever feel like
scheduling a.  It'll even garbage collect a without ever executing it.)

> Further, couldn't you, from IO, FFI into a function that examines the
> source code of some pure function, thus being able to differentiate
> funcitions that are normally "indistinguishable"?

Regular IO is good enough for this.

> I've tried to follow this discussion, but I don't quite understand
> what's so bad about unsafeInterleaveIO - or rather, what's so uniquely
> bad about it.  It seems the same issues can be found in every corner
> of IO. 

jcc