[Twisted-Python] _dumbwin32proc and PIPE_NOWAIT

[Manlio Perillo]

glyph at divmod.com ha scritto:
> On Sat, 30 Sep 2006 01:01:06 +0200, Manlio Perillo
> <manlio_perillo at libero.it> wrote:
>> From the msdn:
> 
> Yep, it's unfortunate that we were forced to use such an ugly API. 
> However, the *correct* way to do this is to use IOCP, and good IOCP
> support has been *years* in the making.  We still haven't got a reliably
> working IOCP buildbot.
> 

Unfortunately I don't know I/O completion ports.

> You're welcome to contribute a patch which cleans this up on the select
> reactor, but frankly I don't se any approach which would be better.
> 
>> I really can't believe that win32 support for asynchronous I/O works
>> with named pipes but not with anonymous pipes...
> 
> Yeah, Windows is pretty terrible.  It's only a problem in some versions,
> but I forget where and when it was fixed.
> 
>> By the way, instead of using a polling, why not to use a separate thread
>> that puts data into a DeferredQueue?
> 
> Because interrupting a blocked thread is a dangerous and error-prone
> task.  It was hard enough getting the thing to just work with
> non-blocking pipe IO.
> 

Not sure to understand here.

> [...]
>> So, why not to create a named pipe with an unique name, know to both the
>> parent and the child process, as an example using an enviroment variable?
> 
> Because that would not be usable as standard output using the usual
> APIs.  This is not just for running other Twisted-using programs in a
> subprocess, but any program which attempts to adhere to UNIX conventions
> around standard IO.
> 

The solution is simple.
Windows *do not* supports POSIX ;-).

If one want to use Windows, the win32eventreactor (or, in future, the
iocp reactor) should be the default (and the only one allowed).

One needs to write a specializd abstract.FileDescriptor class, that use
the Overlapped structure for I/O.

This should allow one to easily use asyncronous I/O support of Window,
not only for sockets, but on all (not many...) 'handles' that support
the asyncronous I/O API.

One can even add support to asyncronous I/O from a console, since
WaitForMultipleObjects supports console handles, and the number of event
pending in the input queue can be retrieved using
GetNumberOfConsoleInputEvents().


By the way: serialport already works only with win32eventreactor.






Regards   Manlio Perillo