Activity

1. joeyh commented on Jun 10, 2020

   

   joeyh

   on Jun 10, 2020

   ContributorAuthor

   More actions

   hClose is indeed interruptable, see the comment here
   https://hackage.haskell.org/package/base-4.14.0.0/docs/src/GHC.IO.Handle.Internals.html#hClose_help

   An alternative to uninterruptibleMask would be to work off a worker thread to do all the closing etc, and wait on it before returning. That insulates it from receiving async exceptions, and won't prevent the program from being interrupted by ctrl-c while it's running.
2. snoyberg commented on Jun 11, 2020

   

   snoyberg

   on Jun 11, 2020

   Collaborator

   More actions

   This topic is an ongoing debate in the Haskell community. I agree with uninterruptible being the right behavior for cleanups, and wish bracket worked that way. I'm not sure if it's a good idea to change an existing function in a core library with a difficult-to-notice semantics change, however.
3. nh2 commented on Feb 8, 2026

   

   nh2

   on Feb 8, 2026

   Member

   More actions

   Investigation of "acquire" part of bracket

   Slightly tangential to this, I looked into whether the "acquire" part of bracket in withCreateProcess_ uses Interruptible Operations.

   Details

   Call chain starting from callProcess in process-1.6.26.1:

   withCreateProcess_ fun c action =
       C.bracketOnError (createProcess_ fun c) cleanupProcess  -- calls `createProcess_`

   createProcess_ msg proc_ = unwrapHandles `fmap` createProcess_Internal msg proc_ -- calls `createProcess_Internal`

   The createProcess_Internal code looks correct to me so far, at least I couldn't spot any interruptible operations after the call to c_runInteractiveProcess.

   But I think that funciton, and createProcess_, should both gain Haddocks that say This function does not use Interruptible Operations (link) after the process is launched, so when used in "Control.Exception.bracket", the "release" function is guaranteed to run.

   Downstream streaming-process use

   The same invariant then needs to be added to streamingProcess_ from streaming-commons, as it, too, is used in bracket "acquire"s, and it calls createProcess_. However, streamingProcess_ cannot just state this, because it is not under its sole control: It does

       let (getStdin, stdinStream) = isStdStream
   
       createProcess_ ...
   
       (,,,)
         A.<$> getStdin stdinH
         A.<*> getStdout stdoutH
           <*> getStderr stderrH
           <*> return (StreamingProcessHandle ph ec close)

   at the end, where the functions getStdin are arbitrary IO actions from typeclass InputSource that the caller can supply ( isStdStream :: (Maybe Handle -> IO a, Maybe StdStream)).

   So InputSource and OutputSink should really also have Haddocks that say that these must not use Interruptible Operations.

   However, a 1 of the 4 provided instances of those, ClosedStream, already violates this requirement, as it calls hClose, which was found interruptible above.

   instance InputSource ClosedStream where
       isStdStream = (\(Just h) -> hClose h >> return ClosedStream, Just CreatePipe)
   
   instance OutputSink ClosedStream where
       osStdStream = (\(Just h) -> hClose h >> return ClosedStream, Just CreatePipe)

   So this suggests that streaming-commons can leak its subprocess under async exceptions already in the "acquire" part of bracket.

   ---

   (I know this is the process issue tracker, not the one for streaming-commons, but posting this info here anyway because it's a common way to call process, e.g. conduit-extra calls streamingProcess in 3 places.)

   typed-process has a similar setup which I haven't fully investigated yet (and there's also that fpco/typed-process#38).