Final bikeshedding call: Fixing Control.Exception.bracket

[Bardur Arantsson]

On 2014-11-21 18:22, Gregory Collins wrote:
> New post from Yuras provides food for thought:
> https://github.com/Yuras/io-region/wiki/Handling-%28async%29-exceptions-in-haskell:-pushing-bracket-to-the-limits
> 
> In particular he points out a case for which uninterruptibleMask will cause
> unkillable threads: let's say hClose blocks flushing the output to a file,
> but the write fails because of a hardware error and blocks forever.

There's no such thing as a hardware error that blocks forever. At least
not on any sane kernel.

> (Alternatively, imagine the file is on NFS and you get a cable cut between
> the two machines). The thread executing hClose in the cleanup action
> becomes unkillable.

This is quite standard for NFS on Linux. Any process accessing a
resource on NFS automatically becomes unkillable on Linux if you cut the
cable -- that's because it gets stuck in the system call. (Theoretically
it should be possible to specify timeouts and such, but I've never been
able to get timeouts on these things working properly/reliably. The
process just gets stuck forever regardless of what you do. Ctrl-C
doesn't work. "Kill -9" doesn't work. Etc. YMMV.) There's nothing any
application can do about this regardless of "interruptible/uninterruptible".

NFS is fundamentally broken on Linux and probably on all other platforms
too.

Anyway: Could we not just agree to see what happens when this change
goes live? People are used to a X.0 release having potential problems
and conservative souls can always stay on (X-1).Y until potential kinks
in the X series are worked out. (Which I would assume they would do anyway.)

Hopefully, there'll also at least a couple of release candidates where
this can be tested in practice. It's not like this is hard to roll the
change back if it should prove problematic.

Regards,