Configuring System.Timeout.timeout for masked asynchronous exceptions

The direct answer

No exception-based timeout can cancel an action while it is inside uninterruptibleMask, and this is by design, not a bug. System.Timeout.timeout works by forking a delay thread that calls throwTo to deliver an exception to the worker. GHC only delivers asynchronous exceptions at points where the target thread is interruptible. Inside mask, delivery is deferred to the next interruptible point; inside uninterruptibleMask, even the throwing thread blocks until the mask region exits. So if your action wraps a long computation in uninterruptibleMask, the timeout fires only after that region ends — there is no configuration of timeout that changes this.

Why masking exists and what breaking it would cost

uninterruptibleMask is the foundation of resource safety in Haskell: bracket, finally, and withMVar rely on it to guarantee that cleanup actions (releasing locks, closing handles) run to completion even when an exception arrives mid-cleanup. If a timeout could preempt uninterruptible code, an exception landing inside a release action could leak a lock or leave an MVar permanently empty, producing deadlocks. Existing code that depends on masking is therefore not merely inconvenienced by the current behavior — it is protected by it. Any design that promises hard preemption of uninterruptible regions is unsound and should be rejected.

What a cooperative STM TVar design actually guarantees

A cooperative scheme — a timer thread writing to a TVar, with the worker polling it — guarantees timely detection of expiry, not timely interruption. The worker still overruns until it reaches a check point. A long pure computation or a blocking FFI call that never polls will blow through the deadline exactly as it does today. The real costs are:

• Interface change: the action must accept and honor a cancellation token, so the combinator no longer works on arbitrary IO a the way timeout does. It is effectively a different function, not a mode of the same one.
• Overhead: modest — an atomically read per iteration — but nonzero, and the checks must be threaded through the whole call tree.
• Latency: worst-case overrun equals the poll interval, so check frequency must be chosen deliberately for tight deadlines.

Recommendation

1. Keep exception-based timeout as the default; document that actions needing hard deadlines must not hold uninterruptibleMask across long operations.
2. Offer cooperative cancellation as a separate combinator taking a token-aware action, rather than a strategy flag on timeout — the signatures genuinely differ.
3. For truly untimed opaque work, run it in a separate process (or accept that an abandoned OS thread may leak if it later unblocks).

Verifying the behavior

Confirm on your installed GHC/base version, since System.Timeout internals have varied across releases:

import Control.Concurrent (threadDelay)
import Control.Exception (uninterruptibleMask_)
import System.Timeout (timeout)

main :: IO ()
main = do
  r <- timeout 1000000 $ uninterruptibleMask_ (threadDelay 3000000)
  print r  -- returns Nothing only after ~3s, not 1s

If this prints after roughly three seconds, masking is deferring delivery as expected. Also inspect the System.Timeout source in your installed base package to confirm the throwTo-based implementation, and test that bracket cleanup inside the masked action completes under whichever strategy you adopt.