On Fri, Nov 23, 2001 at 09:38:35AM -0000, Simon Marlow wrote:
[...]
However, I agree that sometimes you really want to be able to do this, so perhaps we need another form of 'block' which doesn't allow *any* exceptions to be delivered, for those times when you know that the time spent waiting in an interruptible operation is going to be bounded.
But even things like putStr can block for an unbounded amount of time. E.g. stdout is a pipe and the reader just doesn't read it for n hours (n unknown), etc.
Sure, which is why we don't allow the programmer to make these non-interruptible. But there are other ways to shoot yourself in the foot: you can go into an infinite loop inside a block, for example. I think there are certain cases where you want to break the rules slightly, and force a particular interruptible operation to be non-interruptible, so that you can guarantee a particular sequence will always run to completion. Sometimes there's just no way to get where you're going otherwise. In the example above, the programmer might know that the pipe is always going to be read within a certain time. You could spin instead of blocking in many cases: for MVars we have the non-blocking tryTakeMVar and tryPutMVar, but for IO we only have hInputReady which works if you're the only thread using that particular Handle, otherwise there's a race window between calling hInputReady and actually doing the IO. So suppose the programmer is going to use the non-blocking versions of these primitives and poll the resource instead of waiting for it. We might as well provide non-interruptible blocking operations (or a non-interruptible version of 'block') and save ourselves some CPU cycles. The onus is on the programmer to ensure that the sequence can't block indefinitely. Cheers, Simon