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