
Le Tue, 5 Mar 2013 20:39:55 +1300, Robert Collins <robertc@robertcollins.net> a écrit :
On 5 March 2013 20:31, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 5 Mar 2013 10:50:01 +1300
I didn't know about that. I wonder, what happens if the standard input is redirected? Also, is it able to read actual raw bytes? INPUT_RECORD looks rather specialized: http://msdn.microsoft.com/en-us/library/ms683499%28v=vs.85%29.aspx
I don't know; cygwin's source may, or we could get someone with a Windows machine to do some testing.
Apparently you need ReadConsole to read bytes, not ReadConsoleInput: http://msdn.microsoft.com/en-us/library/ms684958%28v=vs.85%29.aspx However, none of those functions is technically non-blocking. You can poll the console using one of the wait functions, but there is an important caveat for ReadConsole: « If the input buffer contains input events other than keyboard events (such as mouse events or window-resizing events), they are discarded. Those events can only be read by using the ReadConsoleInput function. » So it seems ReadConsole can block even though you think some data is available.
It's not non-blocking then, it's asynchronous (it's blocking but in another thread ;-)).
Well... its not in another userspace thread - its near-identical in implementation to Linux AIO : the kernel takes care of it. The deliver mechanism is however very different (you sleep and the kernel calls you back).
It's still not non-blocking. On a non-blocking stream, a read fails when no data is available; you have to try reading again later. With asynchronous I/O, the blocking read is scheduled in the background, and it will call you back when finished. It's a different mode of operation. Regards Antoine.