#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