#4514: IO manager can deadlock if a file descriptor is closed behind its back
---------------------------------+------------------------------------------
Reporter: adept | Owner: bos
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.0.1 | Keywords:
Testcase: | Blockedby:
Os: Linux | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
Comment(by bos):
Never mind, GHC's preprocessor and I were having a friendly disagreement
about what version it ''really'' was. Ha ha, very jolly, misunderstanding
cleared up, backs clapped all around for general good humour.
Right. So the bug was indeed that we were sneaking around behind our very
own backs, calling {{{close}}} and then hoping that {{{epoll}}} might do
something sensible and notify us that the file descriptor had closed. No
such luck, as {{{epoll}}} is a demanding and spiteful deity, and will not
help those who cannot help themselves.
My first attempt at a fix was simply to have {{{sClose}}} and friends call
{{{fdWasClosed}}}, which conveniently already existed. And sure enough,
this did the trick.
There's a wrinkle, though: I'm pretty sure we need the I/O manager thread
itself to drop the queued callbacks and then {{{close}}} the file
descriptor. Otherwise, we're susceptible to nasty race conditions: if we
{{{close}}} then drop callbacks, we could drop callbacks for a new file
descriptor. If we drop callbacks then {{{close}}}, another thread could
register a new callback after we've dropped them but before we've reached
{{{close}}}.
That'll complicate things a bit.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4514#comment:16>
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
