Asynchronous exception wormholes kill modularity

[Tyson Whitehead]

On April 9, 2010 06:05:36 Simon Marlow wrote:
> On 08/04/2010 21:20, Tyson Whitehead wrote:
> > Of course you've then got the problem of umask having to produce a valid
> > value even when IO a was aborted, so you would have to go with something
> > like
> >
> > unmask :: a ->  IO a ->  IO a
> >
> > where the first a gets returned if the IO a computation gets aborted by
> > an exception.  The original problem code would then go from
>
> I haven't seen anyone else asking for this kind of design, and it's
> quite different to both what we have now and the new proposal.  What
> advantages would this have, do you think?

My understanding was that, for a given block of code, it would be nice to be 
able to ensure asynchronous exceptions are always unblocked.  This is 
something that the nested design doesn't give you because it is going to 
depend on the context in which a block of code is ran.

My understanding about the problem with the currently implemented design is 
that asynchronous exception will still abort the normal evaluation flow when 
ever a called routine unblocked exceptions as this then allows them to be 
turned into standard synchronous exceptions.

My suggestion was then aimed at seeing if their was a way to ensure the 
standard evaluation flow resumed.  In retrospect, I'm not sure it was a good 
suggestion.  Although it ensures modifyMVar leaves things in a consistent 
state, it is likely less than desirable for the function calling modifyMVar to 
have have control returned to it with no idea whether the modification was 
successful or not until it unblocks exceptions sometime later.

Looking back at the original problem, I was wondering if the problem was 
simply that the understanding the block gives you an "atomic transaction" is 
simply not true.  Thus the outer block of code

block $ do ...
           modifyMVar_ m f
           ...

should be using proper exception wrapping around any resources it acquires to 
ensure that they always get cleaned up.

Of course this then brings you in full circle as you have the problem that an 
"asynchronous exception wormhole" could also occur in your cleanup code.  This 
leads me to conclude that nesting really is the correct solution, and the 
answer to the problem of exception being potentially blocked for too long is 
that properly written code should strive to limit the amount of time they are 
blocked (i.e., really just for the acquisition and releasing of resources).

A different, but related issue then might be what are alternate form of the 
primitives block and unblock to help ensure they aren't abused?  Something 
like bracket where the acquisition and release run with exception blocked and 
the body with them re-enabled?  Anyways, enough of my rambling, I'll let you 
guys get back to figuring out how to ensure that nesting is not abused.

Cheers!  -Tyson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/libraries/attachments/20100409/9f52b845/attachment.bin