#4514: IO manager can deadlock if a file descriptor is closed behind its back
------------------------------------------+---------------------------------
Reporter: adept | Owner: bos
Type: bug | Status: patch
Priority: high | Milestone: 7.0.2
Component: Runtime System | Version: 7.0.1
Resolution: | Keywords:
Testcase: | Blockedby:
Difficulty: | Os: Linux
Blocking: | Architecture: Unknown/Multiple
Failure: Incorrect result at runtime |
------------------------------------------+---------------------------------
Comment(by simonmar):
Replying to [comment:33 bos]:
> Goddamn Trac. Augh.
>
> * The `fdWasClosed` function that we added during 6.13 development was
subject to a race condition: you could mark an fd as closed after another
thread had performed an open or similar that could reuse that fd.
>
> * The new `closeFd` function is necessary to close that race. It
manages this by closing the fd while holding an `MVar`, so another thread
can't race in and register the fd.
>
> * Why does `closeFd` accept an action as parameter? Because under
Windows, you have to use different functions to close a file descriptor
depending on whether it's owned by Winsock or the rest of win32.
>
> * If the name should be something like `closeFdWith` to be more
descriptive, that's fine (please let me know if you have a preference), as
my purpose is to close the race :-)
>
> * Why should `closeFdWith` be exported from `Control.Concurrent`?
Because `threadWaitRead` and `threadWaitWrite` already are, and
`closeFdWith` must be used with those functions now to guarantee race-free
closing.
`threadWaitRead` and `threadWaitWrite` should not really be exported by
`Control.Concurrent`, they're only there for historical reasons. They
have a non-portable API (dependent on file descrxiptors, and using `Int`
rather than `Fd` too). They also aren't very useful for most people,
because they have to be used very carefully with non-blocking I/O
operations.
I think something in `System.Event` or `GHC.IO` would be more appropriate
for `closeFd`. We should move `threadWaitRead` and `threadWaitWrite` in
due course too; either `System.Event` or `GHC.IO.FD` would be the best
place for those.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4514#comment:36>
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
