Final bikeshedding call: Fixing Control.Exception.bracket

[John Lato]

On Thu Nov 13 2014 at 1:56:18 PM Bardur Arantsson <spam at scientician.net>
wrote:

> On 2014-11-13 04:25, Gregory Collins wrote:
> > On Wed, Nov 12, 2014 at 6:37 PM, John Lato <jwlato at gmail.com> wrote:
> >
> >> Do you think the current resource leaking issue is not particularly
> >> significant, or do you tend to think it's an issue that should be fixed,
> >> but you're weighting the unknown costs much more than I am?
> >
> >
> > I'm just change averse :)
> >
> > We have traditionally been very cavalier in the Haskell community about
> > gratuitously changing APIs in ways that break user code, and in my
> opinion
> > this is very bad and creates a perception for users that choosing Haskell
> > is just going to end up creating work for them. In this regard I think
> it's
> > very good to be conservative -- this function has been documented to
> behave
> > in a certain way and you can be sure that somebody, somewhere relies on
> > that behavior.
> >
>

I agree, and the fast pace of breaking changes has certainly required a lot
of my time to deal with.  But what about people who rely on bracket/hClose
working properly?  Do we just say, "yes, it can leak, if it's really a
problem go use this function that the documentation strongly warns you not
to use"?  Should we update the documentation of hClose to warn that it
might not work?


> I can certainly understand this perspective and *ordinarily* I'd agree
> with the stance that compatibility shouldn't be broken willy-nilly.
>
> That said, popularity isn't everything. Sometimes correctness *must*
> trump the convenience of not having to change client code. And clearly
> people haven't been leaving Haskell in droves on these grounds, so....
>
> > Normally I argue strongly for this perspective (because it feels like few
> > people do) on less serious things like changing function types or names,
> > because those things break builds and cause people to scramble to restore
> > their libraries to compatibility all at once after the GHC release. The
> > consequences of *this* particular change, however, have the potential to
> be
> > a lot worse than just making busywork for people: programs will silently
> > continue to compile and then start deadlocking in mysterious (and likely
> > rare/"race-condition-y") ways.
> >
>
> ... but such code is already broken in a *worse* way, namely in a
> hard-to-discover and hard-to-debug way. I'll take a nearly-instantly
> reproducible deadlock over a "reproducible-only-once-in-a-blue-moon"
> resource leak bug any day.
>
> This is what convinced me (and others) the last time around. What's
> changed since the last time this was discussed?
>

This is my perspective as well.

Consider hClose.  It currently isn't safe in the presence of async
exceptions.  I do not believe it can be made safe without
uninterruptibleMask or similar.  Doing so would certainly increase the
possibility of deadlocks in the same way this proposal would.  This is
another reason I'm discounting the downside here; I don't see any way to
avoid it while fixing the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141113/d333fd0a/attachment.html>