[Python-ideas] BufferedIO and detach

[Antoine Pitrou]

Le Tue, 5 Mar 2013 20:39:55 +1300,
Robert Collins
<robertc at robertcollins.net> a écrit :
> On 5 March 2013 20:31, Antoine Pitrou
> <solipsis at 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.