Question

I’m writing a database library of sorts. The basic function it exports is the following:

withDatabase :: FilePath -> (DBHandle -> IO a) -> IO a

which automatically manages the lifetime of database handles.

Internally, withDatabase uses the bracket function from Control.Exception.

withDatabase path f = bracket (openDatabase path) closeDatabase f

In my specific case, openDatabase may perform some significant I/O and thus block for a long time. For this reason, I would like to run some part of it with asynchronous exceptions unmasked. A (simplified) implementation could be:

openDatabase :: FilePath -> IO DBHandle
openDatabase path = mask $ \restore -> do
                      h <- openFile path ReadWriteMode
                      restore (doLongStuff h) `onException` (hClose h)
                      ...
                      return (DBHandle h)

I’m not sure this code is producing the effect I intend.

Let’s look back at withDatabase, this time replacing bracket with its definition:

withDatabase path f = mask $ \restore -> do
  h <- openDatabase path
  r <- restore (f h) `onException` closeDatabase h
  _ <- closeDatabase h
  return r

At a certain point in the execution, the call stack becomes the following:

\- withDatabase
 \- mask
  \- openDatabase
   \- mask
    \- restore
     \- doLongStuff

The documentation for the Control.Exception module has something about nested calls to mask:

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.

My understanding of this description is that doLongStuff will work with asynchronous exceptions masked and not, as I would like, unblocked.

In my real code, I cannot move neither openFile nor doLongStuff out of openDatabase: in fact, openDatabase may open any number of files and/or perform various I/Os before “deciding” which handle it wants to return to withDatabase. Given this contraint, is there any way to make doLongStuff interruptible even if it happens to run inside a nested mask call?

Answer 1

Is doLongStuff being done on the database? If so, it may already be interruptible. See the section on Interruptible Operations, which states that any function which may block, including most functions that perform IO, can be interrupted even within the scope of a mask.

If you’re not sure if doLongStuff is interruptible or not (depends which functions it uses), then you can either use allowInterrupt to poll for async exceptions within masked code, or alternatively use an MVar to synchronize reading from the DB. This would work because most MVar operations are interruptible themselves, allowing the larger function to also be interruptible.