#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 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...
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. Maybe `yield` is already this? Or no-op with cleanup argument to
call in a case of exception.
> 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.
So yes, we introduced `mask` because you should not be able to unmask if
not allowed to. And before you could. There was no other mechanism in
place. Currently, there is: do you have a restore function (a token, a
[http://en.wikipedia.org/wiki/Capability-based_security capability]) or
not.
Look what we do internally in our code: we mask and then pass restore to
those parts where we want to allow them to unmask. But why would we limit
this only to the code somebody writes him/herself. Why shouldn't this be
modular in a sense that masking is done somewhere and unmasking is done
somewhere else, in somebody else's code/module. It is just about
modularity. If I would wrote all code by myself I would simply pass it
around as necessary. But now I want to make a contract/API to my module so
that things can be modular.
And if somebody does not want to give my module power to restore he/she
can simply give me `id` function.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4810#comment:6>
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
