John Meacham wrote:
On Wed, May 03, 2006 at 12:07:19PM +0100, Simon Marlow wrote:
This won't affect Handle I/O unfortunately, because we need block to
protect against asynchronous exceptions. I'm still not certain you
won't need that in the stream library, too: check any stateful code (eg..
buffering) and imagine what happens if an exception is raised at an
arbitrary point.
Is unlocking the lock really the right thing to do on an asynchronous
exception? A lock isn't a resource, it is a primitive needed to enforce
correctness of your program. You use them to protect critical sections
and chances are aborting a critical section at an arbitrary point would
leave your program in an incorrect state, just delaying your deadlock or
hiding the errors silently somewhere where they can bite you later.
Quite right, which is why in GHC's IO library we use "block" around most
(all?) Handle operations so that we don't receive asynchronous exceptions.
the main uses of block are:
- acquiring a resource atomically (eg. withMVar)
- maintaining invariants of shared state
STM gives you an alternative way to do both of these, but you still
sometimes need 'block' for sequences of IO operations that you don't
want to be interrupted.
hmmm... ever think asynchronous exceptions are more trouble then they
are worth...
Sometimes, but I haven't found a better alternative, and asynchronous
exceptions in GHC are *far* easier to handle than in other languages.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
