#4810: Versions of bracket without masking acquire action
---------------------------------+------------------------------------------
Reporter: mitar | Owner:
Type: proposal | Status: new
Priority: normal | Milestone:
Component: libraries/base | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by simonmar):
Replying to [comment:6 mitar]:
> Replying to [comment:5 simonmar]:
> > Remember that `acquire` will still be interruptible, since it is
within `mask`, not `uninterruptibleMask`. Is there really a problem here?
>
> Yes, for example I have a lengthy acquire which calls FFI. Code in FFI
is not interruptible. And code calling it and preparing does not use any
IO actions, MVars...
FFI isn't interruptible whether you're inside `mask` or not.
> Maybe we could introduce an interruptible no-op IO operation which would
just allow that at that moment exception is thrown even if the section is
masked.
Now that's a very good idea. How about
{{{
allowInterrupt :: IO ()
}}}
> > But that breaks the abstraction - you shouldn't be able to unmask
unconditionally. That's why we moved to `mask` instead of
`block`/`unblock`.
>
> Buy you can unmask only if you are allowed to. So if I am developer of
the code which is called with such `bracketWithUnmask` then I know that
caller allows me to unmask as necessary. And vice versa, if I am calling
with `bracketWithUnmask` I know that I am allowing the code I am calling
to unmask. This is much much different to the situation before, where you
could not make any assumption about this and you could not make a
contract/API which would define this.
But consider a library function that uses `bracketWithUnmask`. If it is
called inside a `mask`, then it should not be able to unmask. This was
the problem that we fixed with `mask`: that's why there is no unmask
operation any more.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4810#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
