[Twisted-Python] _dumbwin32proc and PIPE_NOWAIT

[glyph at divmod.com]

I think I get it now.  The actual issue you're talking about is console IO.  The thing about the efficiency of polling is a side issue.

On Sat, 30 Sep 2006 13:06:03 +0200, Manlio Perillo <manlio_perillo at libero.it> wrote:
>glyph at divmod.com ha scritto:

>The problem is simple:
>if I want to do asyncronous I/O with Windows I don't have an unique
>'interface'.

Yes.  Take it up with Microsoft :).  Even within their native event loops, things are inconsistent.

>Is win32eventreactor not working and not tested?

It's tested, but it's not working.  See http://twistedmatrix.com/buildbot/ - you'll notice the "win32-win32er" column is always red.  It's also limited because it still allows only 63 objects.

>You did not mention it in the "removing unsupported reactors in twisted"
>thread.

It has maintainers, it has a buildbot, and it's been gradually decreasing its number of failing tests over time.  It didn't seem like a candidate for removal.

>I have write it, now stdio works ;-).

>Unfortunately it is not very efficient since:
>- it uses _pollingfile (not a real porblem)
>- it reads raw keyboard input and have to do all low level stuff like
>  '\b' handling, '\r' conversion, and so

It's very hard to do these things efficiently, so I'm not too worried about that.  We also don't have a lot of programmers interested in Windows support.  My interest in Windows support ends right about at the point where the servers I develop can be successfully tested and developed on win32 :).  Providing functionality in an inefficient implementation at least provides some useful functionality in the meanwhile, and something to optimize later if it becomes important.

>Here is the main code.
>I suspect such a thing will never be accepted into Twisted ;-):

As JP said, it might, with some tests and a patch in the tracker :).

>The _win32stdio module can simply check if the stdin is attached to a
>terminal, so it (hopefully) can support both pipes and consoles.

That would be great.

>Many things can be added, like an emulation of POSIX terminal, callbacks
>for resize events, support for focus in/out, colored output, history
>editing, ...

>[1]
>How can be tested such a thing?

In addition to JP's suggestion, "mock" the actual API you will be testing with, by replacing it in the tests and asserting that the appropriate things are called on the console object that you are passing it.

Both approaches make sense in different situations, and good test coverage will generally do both.