#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 simonmar):
Ok, I see that `hGetBufSome` already has the behaviour that I claimed is
erroneous. That's sad.
I'd really like to declare this to be a bug in the Windows implementation
of Handles, but perhaps that's impractical. I think it might be possible
to implement non-blocking I/O on Windows, but you have to do it
differently for every type of Handle (console, socket, com port etc.). We
do have a working implementation of `hWaitForInput` (see
`libraries/base/cbits/inputReady.c`) but it's horrible.
Maybe deprecating the non-blocking APIs is the right way, since we are
providing the ability to do asynchronous I/O using threads, and that's
much nicer. But before we do that, we should look at how people are using
these APIs. The only user of `hGetBufSome` that I know of, lazy
bytestring, works just fine with the "read a random amount of data"
semantics.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:11>
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
