#4514: IO manager can deadlock if a file descriptor is closed behind its back
---------------------------------+------------------------------------------
Reporter: adept | Owner: bos
Type: bug | Status: patch
Priority: normal | Component: Runtime System
Version: 7.0.1 | Keywords:
Testcase: | Blockedby:
Os: Linux | Blocking:
Architecture: Unknown/Multiple | Failure: Incorrect result at runtime
---------------------------------+------------------------------------------
Changes (by tibbe):
* cc: johan.tib...@… (added)
Comment:
I believe we need to invoke the callbacks, after closing the file
descriptor, instead of just removing them. Otherwise we might leave (non-
dead) threads blocking on `MVar`s forever. Example:
{{{
main = do
s <- listenOn (Service "7000")
forkIO $ do
threadDelay 10000
sClose s
msg <- recv s 1000 -- blocked here forever
}}}
By invoking all the callbacks (with `evtRead` and `evtWrite`) after
closing the file descriptor the threads will retry the read call and fail
(and thus throw an exception) as the file descriptor has gone away. I
think that's the desired behavior when one thread closes a file descriptor
behind another thread's back.
Comments on the patch to network:
* There's a lingering Debug.Trace import.
* We need to test for GHC 7.0.2 (presuming this patch will be in that
version) instead of GHC 7.0.0 to avoid having network fail to compile for
people who use GHC 7.0.1.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4514#comment:19>
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
