#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:7 simonmar]:
> FFI isn't interruptible whether you're inside `mask` or not.
I was not saying otherwise. ;-) Just stating how you can get a lengthy
acquire.
> Now that's a very good idea.
In fact I do not really like it. ;-)
And I do not really see much difference between `allowInterrupt` and
`unblock yield`. You still unmask where you maybe should not (from a
caller point of view). But yes, you couldn't really call something else in
a unblocked context. That is different.
> 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.
Yes, it cannot unmask. The same as normal `bracket` cannot unmask in-
between action if it is called in masked context. There is nothing wrong
with that. What I am arguing for is that if the caller wants to allow
acquire not to be masked, he/she can:
1. call it in an unmasked context
2. call it with `bracketWithUnmask` (sadly, this requires that calling
function have a corresponding type signature, but this is probably also a
good thing as it says that calling function can take advantage of being
able to unmask)
I caller does not want to allow unmasking, he/she can:
1. mask
2. pass `id` to `bracketWithUnmask` (or use a variant of calling function
without restore argument)
And this is the same for library function or for user function. restore
function might not do anything as `mask` was called already in a masked
context. But this is OK.
I am only saying there should be a function in a standard library so that
you do not need to write your own. I think it is completely safe (it does
not introduce unmasking where it should/could not). And I argue that it is
useful for situations where you have lengthy acquire action where you can
handle interrupts (like you should handle them because maybe you are also
using interruptible actions).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4810#comment:8>
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
