From 9edd0b0bc4aea54fe54d7d36923e828e610c013c Mon Sep 17 00:00:00 2001 From: Bas van Dijk Date: Sat, 16 Oct 2010 18:53:12 +0000 Subject: [PATCH] Refer to 'mask' instead of 'block' in documentation of Control.Exception --- Control/Exception.hs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Control/Exception.hs b/Control/Exception.hs index d5d0e4c..c573e3a 100644 --- a/Control/Exception.hs +++ b/Control/Exception.hs @@ -122,7 +122,7 @@ module Control.Exception ( unblock, blocked, - -- *** Applying @block@ to an exception handler + -- *** Applying @mask@ to an exception handler -- $block_handler @@ -258,12 +258,12 @@ to one of the 'catch' family of functions. This is because that is what you want most of the time - it eliminates a common race condition in starting an exception handler, because there may be no exception handler on the stack to handle another exception if one arrives -immediately. If asynchronous exceptions are blocked on entering the +immediately. If asynchronous exceptions are masked on entering the handler, though, we have time to install a new exception handler before being interrupted. If this weren\'t the default, one would have to write something like -> block $ \restore -> +> mask $ \restore -> > catch (restore (...)) > (\e -> handler) @@ -279,7 +279,7 @@ recovering from an asynchronous exception. #interruptible# Some operations are /interruptible/, which means that they can receive -asynchronous exceptions even in the scope of a 'block'. Any function +asynchronous exceptions even in the scope of a 'mask'. Any function which may itself block is defined as interruptible; this includes 'Control.Concurrent.MVar.takeMVar' (but not 'Control.Concurrent.MVar.tryTakeMVar'), -- 1.7.10.4