#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"

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

Reply via email to