Asynchronous Exceptions

[Simon Marlow]

> On Fri, Nov 23, 2001 at 09:38:35AM -0000, Simon Marlow wrote:
>=20
> > [...]
>=20
> > However, I agree that sometimes you really want to be able=20
> 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=20
> that the time
> > spent waiting in an interruptible operation is going to be bounded.
>=20
> 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. =20

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