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-h...
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,