#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
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
