Final bikeshedding call: Fixing Control.Exception.bracket

[John Lato]

 On 10:37, Thu, Nov 13, 2014 Gregory Collins <greg at gregorycollins.net>
wrote:


On Nov 13, 2014 9:54 AM, "John Lato" <jwlato at gmail.com> wrote:

>
> How about this: when is it correct for a cleanup handler to be
interrupted by an async exception and drop its cleanup action into the
void?  I am not sure that is ever correct, although I can see that it might
be useful on rare occasions.

Example: you issue an RPC upon receipt of an exception (perhaps to some
centralized exception logging service). That's safe to try if running under
mask (maybe you're OK with the thread being killed and canceling the RPC),
but not uninterruptible mask.

> Merijn pointed out that either a cleanup is not interruptible, in which
case uninterruptibleMask doesn't change the semantics, or it is
interruptible, in which case that's almost certainly a bug.

Data please :-). The fact is that currently it is possible to use bracket
for control flows that will be unsafe after the proposed change. Maybe
nobody is actually relying on that, but until someone does an audit I don't
think we should accept hand waving assertions like this one way or the
other.

 I think Bardur is right: that sort of thing is a bad idea in general
explicitly because it can lead to deadlock.  It might be possible now, but
I think it should be explicitly disallowed, at least in the common case.

It's possible I have little sympathy for breaking other people's code
because mine has been broken quite frequently, but I still think the
proposal is a step forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/c0220190/attachment-0001.html>