#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------+-------------------------------------------- Reporter: AntoineLatter | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+--------------------------------------------
Comment(by joeyadams): Thanks for the review. > As it stands right now, hGetBuf, hGetBufNonBlocking and hGetBufSome will all read the same amount of data, if the data is available without blocking. I don't think this is the case anymore; see #5843 and commit [https://github.com/ghc/packages- base/commit/370fc0b455f6a03283fbd5c0baa5d08d9115379d 370fc0b]. The issue is that some devices don't support non-blocking I/O (e.g. file handles on Windows). Here's the problematic sequence: * Call `hWaitForInput`. It returns `True` when the buffer is not empty. * Call `hGetBufSome`, which we expect will not block. It first reads bytes from the buffer, then tries to do a "non-blocking" read. Since the non-blocking IO methods block on Windows, `hGetBufSome` blocks, even after it has read some data. So here are some of our options: * Change semantics of `hGetBufSome` so that it will only block if there is no input. However, there is no guarantee that `hGetBufSome` will return all immediately available bytes. * On Windows, simulate nonblocking and IODevice.ready by continuously issuing reads in a forked thread to a buffer, and having I/O functions read from that buffer. * Deprecate `hGetBufNonBlocking`, `hPutBufNonBlocking`, `hWaitForInput`, and the non-blocking `RawIO` and `BufferedIO` methods. Come up with an alternative design that does not require the system to support non- blocking operation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:10> 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