Bugs item #995658, was opened at 2004-07-22 03:00
Message generated for change (Settings changed) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=995658&group_id=8032
Category: libraries/haskell98
Group: 6.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Will Glozer (wglozer)
>Assigned to: Simon Marlow (simonmar)
Summary: hReady always returns True when used on win32 non-Console
Initial Comment:
The hReady function always returns True when called on
a stdin stream that is not a real win32 console stream,
even if there is no data available. This causes
blocking of programs that depend on hReady to return
true only when there is at least one character available.
The following program will demonstrate this behavior
when run from inside an msys rxvt window, an emacs
shell buffer, etc:
-------------------------
import IO
import Monad
main = do ready <- hReady stdin
when ready $ do
putStr("stdin is ready\n")
hFlush(stdout)
do c <- getChar
putStr("getChar read '" ++ [c] ++ "'\n")
hFlush(stdout)
getChar
main
-------------------------
I've tested this on Windows XP SP1, using the latest
ghc 6.2.1.
----------------------------------------------------------------------
Comment By: Will Glozer (wglozer)
Date: 2004-07-23 21:30
Message:
Logged In: YES
user_id=152223
After further investigation it looks like
libraries/base/cbits/inputReady.c uses
WaitForMultipleObjects(...) on the stdin handle, and this
method always returns that the handle is available, even
when there is no input.
I've fixed this by calling PeekNamedPipe(...) if the return
code is WAIT_OBJECT_0, and if PeekNamedPipe(...) succeeds
return 1 if any bytes are available, otherwise 0.
PeekNamedPipe will fail if the handle isn't a pipe, in which
case I'm just returning 1, the same as if the code wasn't
there at all.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=108032&aid=995658&group_id=8032
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
