It's quite hard to implement mutable data structures in presence of asynchronous exceptions. Since exception can arise at any point, it is not possible to guarantee atomicity of operation, hence mutable data structure may remain in incorrect state in case of interruption. One can certainly use maskAsyncExceptions# and friends to protect critical regions, but masking function are living in IO, mutable data structures on other hand trend to be state-polymorphic (to allow it usage in ST). This lead to conflicting requirements: - One should not care about asynchronous exceptions inside ST (it is not possible to catch exception in ST, hence not possible to use something in invalid state). More over, it is not even possible to do write “exception-safe” code, because masking functions not available. - One should provide accurate masking then using same data structures in IO. So I want do discuss several questions topics on this case. 1. Impact. Are async exceptions really common? Would not be easier to say: “ok, things can go bad if you combine async exceptions with mutable data structures, just don't do it”. 2. Documentation. Should library authors explicitly mention async exceptions safety? For example https://hackage.haskell.org/package/hashtables – is it async exceptions safe when used in IO? Or even worse https://hackage.haskell.org/package/ghc-prim-0.5.1.0/docs/GHC-Prim.html#v:re... - what will happened in case of async exception? This functions is sate-polimorphic, will it implicitly mask exceptions if used from IO? 3. Best practices. How should we deal with problem? Is creating separate versions of code for ST and IO is the only way? Probably it is possible to add “mask” to something like https://hackage.haskell.org/package/primitive-0.6.2.0/docs/Control-Monad-Pri... emit mask in IO instance and NOOP in ST version? Or maybe somebody know better patterns for async exeption safe code? -- Sincerely, Stanislav Chernichkin.