#4934: threadWaitRead works incorrectly on nonthreaded RTS
-------------------------------+--------------------------------------------
Reporter: slyfox | Owner: simonmar
Type: bug | Status: infoneeded
Priority: high | Milestone: 7.0.3
Component: Runtime System | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64) | Failure: Incorrect result at runtime
-------------------------------+--------------------------------------------
Changes (by simonmar):
* cc: tibbe, bos (added)
Comment:
This is the way it has always worked. The problem is that when `select()`
finds that one of the file descriptors has been closed, it returns an
error, but doesn't tell you which one it was, so in that case we inform
all the blocked threads that they should wake up, and retry whatever
operation they were doing, which will result in the appropriate exception
being thrown. I presume that `epoll` is able to determine which file
descriptor is erroneous and generate the exception from `threadWaitRead`
instead.
So typical uses of `threadWaitRead` won't notice the difference. We could
make the `epoll` backend ignore the exception, but that doesn't seem
right. Personally I'm happy to leave things as they are, but document
that `threadWaitRead` may or may not raise an exception if the FD is
closed (actually I'd like to remove `threadWaitRead` from
`Control.Concurrent` anyway, it's really an internal API).
tibbe/bos, any thoughts?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4934#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
