[Haskell-cafe] What unsafeInterleaveIO is unsafe
jonathanccast at fastmail.fm
Wed Mar 18 16:19:28 EDT 2009
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.
More information about the Haskell-Cafe