#4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure
-------------------------------+--------------------------------------------
  Reporter:  AntoineLatter     |          Owner:  joeyadams       
      Type:  bug               |         Status:  new             
  Priority:  normal            |      Milestone:                  
 Component:  libraries/base    |        Version:  7.6.1           
Resolution:                    |       Keywords:                  
        Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  Runtime crash     |     Difficulty:                  
  Testcase:                    |      Blockedby:                  
  Blocking:                    |        Related:                  
-------------------------------+--------------------------------------------
Changes (by joeyadams):

  * owner:  => joeyadams


Comment:

 I plan to fix this by adding the following methods to BufferedIO:

 {{{
   readBuffered :: dev -> Buffer Word8 -> Ptr Word8 -> Int -> IO (Int,
 Buffer Word8)

   readBuffered0 :: dev -> Buffer Word8 -> Ptr Word8 -> Int -> IO (Maybe
 Int, Buffer Word8)

   writeBuffered :: dev
                 -> Bool             -- ^ If 'True', flush after writing.
                 -> Buffer Word8
                 -> Ptr Word8
                 -> Int
                 -> IO (Buffer Word8)

   writeBuffered0 :: dev
                  -> Bool -> Buffer Word8 -> Ptr Word8 -> Int
                  -> IO (Int, Buffer Word8)
 }}}

 The default implementations will use the fill and flush methods of
 BufferedIO, but an instance may provide more efficient substitutes.
 RawIO-based methods will be provided, which will go directly to the device
 when possible and efficient.

 This will move a lot of the complexity of the hGetBuf, hPutBuf, etc.
 functions out of GHC.IO.Handle.Text and into GHC.IO.BufferedIO (in the
 form of default methods and RawIO drop-ins).

 I will be changing the behavior of hGetBufSome slightly: if the buffer is
 not empty, it will fetch its contents and return immediately, rather than
 trying to squeeze more bytes out of the device with non-blocking fills and
 reads.  See #5843

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4144#comment:5>
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

Reply via email to