mask package:rebase

Executes an IO computation with asynchronous exceptions masked. That is, any thread which attempts to raise an exception in the current thread with throwTo will be blocked until asynchronous exceptions are unmasked again. The argument passed to mask is a function that takes as its argument another function, which can be used to restore the prevailing masking state within the context of the masked computation. For example, a common way to use mask is to protect the acquisition of a resource:
mask $ \restore -> do
x <- acquire
restore (do_something_with x) `onException` release
release
This code guarantees that acquire is paired with release, by masking asynchronous exceptions for the critical parts. (Rather than write this code yourself, it would be better to use bracket which abstracts the general pattern). Note that the restore action passed to the argument to mask does not necessarily unmask asynchronous exceptions, it just restores the masking state to that of the enclosing context. Thus if asynchronous exceptions are already masked, mask cannot be used to unmask exceptions again. This is so that if you call a library function with exceptions masked, you can be sure that the library call will not be able to unmask exceptions again. If you are writing library code and need to use asynchronous exceptions, the only way is to create a new thread; see forkIOWithUnmask. Asynchronous exceptions may still be received while in the masked state if the masked thread blocks in certain ways; see Control.Exception#interruptible. Threads created by forkIO inherit the MaskingState from the parent; that is, to start a thread in the MaskedInterruptible state, use mask_ $ forkIO .... This is particularly useful if you need to establish an exception handler in the forked thread before any asynchronous exceptions are received. To create a new thread in an unmasked state use forkIOWithUnmask.
Like mask, but does not pass a restore action to the argument.
the state during mask: asynchronous exceptions are masked, but blocking operations may still be interrupted
the state during uninterruptibleMask: asynchronous exceptions are masked, and blocking operations may not be interrupted
Describes the behaviour of a thread when an asynchronous exception is received.
asynchronous exceptions are unmasked (the normal state)
Like forkIO, but the child thread is passed a function that can be used to unmask asynchronous exceptions. This function is typically used in the following way
... mask_ $ forkIOWithUnmask $ \unmask ->
catch (unmask ...) handler
so that the exception handler in the child thread is established with asynchronous exceptions masked, meanwhile the main body of the child thread is executed in the unmasked state. Note that the unmask function passed to the child thread should only be used in that thread; the behaviour is undefined if it is invoked in a different thread.
Like forkIOWithUnmask, but the child thread is a bound thread, as with forkOS.
Like forkIOWithUnmask, but the child thread is pinned to the given CPU, as with forkOn.
Returns the MaskingState for the current thread.
Like modifyMVar, but the IO action in the second argument is executed with asynchronous exceptions masked.
Like modifyMVar_, but the IO action in the second argument is executed with asynchronous exceptions masked.
Like mask, but the masked computation is not interruptible (see Control.Exception#interruptible). THIS SHOULD BE USED WITH GREAT CARE, because if a thread executing in uninterruptibleMask blocks for any reason, then the thread (and possibly the program, if this is the main thread) will be unresponsive and unkillable. This function should only be necessary if you need to mask exceptions around an interruptible operation, and you can guarantee that the interruptible operation will only block for a short period of time.
Like uninterruptibleMask, but does not pass a restore action to the argument.
Like withMVar, but the IO action in the second argument is executed with asynchronous exceptions masked.