#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

 I don't think this is the case anymore; see #5843 and commit
 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

Reply via email to