#5843: hGetBufSome blocks when all available input is buffered (on Windows only)
-----------------------------------------+----------------------------------
Reporter: joeyadams | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries/base
Version: 7.2.2 | Keywords:
Os: Windows | Architecture: x86
Failure: Incorrect result at runtime | Testcase:
Blockedby: | Blocking:
Related: |
-----------------------------------------+----------------------------------
Comment(by joeyadams):
Sorry, I pressed Create Ticket when I meant to press Preview.
I did some debug traces, and found that the flow of calls is as follows:
hGetSome
hGetBufSome
bufReadNBNonEmpty (second occurrence)
bufReadNBEmpty
Buffered.fillReadBuffer0
The Buffered.fillReadBuffer0 call blocks on Windows, even though it
shouldn't:
{{{
-- | reads bytes into the buffer without blocking. Returns the
-- number of bytes read (Nothing indicates end-of-file), and the new
-- buffer.
fillReadBuffer0 :: dev -> Buffer Word8 -> IO (Maybe Int, Buffer Word8)
}}}
Digging deeper, I think fillReadBuffer0 ultimately boils down to a call to
fdReady. But I'm not 100% sure.
hWaitForInput, which also calls fdReady, does in fact work on Windows.
Perhaps readRawBufferPtrNoBlock isn't calling fdReady correctly. Here is
how GHC.IO.FD.ready calls it (for FD):
{{{
#if defined(mingw32_HOST_OS)
(fromIntegral $ fromEnum $ fdIsSocket fd)
#else
0
#endif
}}}
And here is how readRawBufferPtrNoBlock calls it:
{{{
| otherwise = do r <- unsafe_fdReady (fdFD fd) 0 0 0
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5843#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
