[Twisted-Python] _dumbwin32proc and PIPE_NOWAIT

[glyph at divmod.com]

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

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

That's unfortunate, but I'm not surprised :).

>> 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.

"threads are bad"

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

It does, however, support standard IO, at least well enough for a large chunk of applications.  Although it's not as well supported as on "POSIX" platforms, there are plenty of programs that produce output which Twisted can happily parse semi-asynchronously using the current strategy.  Why on earth would you want to remove it?  It serves a purpose (cross-platform multi-process communication and control), it works, it's tested.

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

win32eventreactor can only support 64 sockets.  The IOCP reactor currently has several issues and is missing, e.g. SSL support.  While true asynchronous I/O and GUI event loop integration have their advantages, the primary feature of the select reactor on Windows is that it actually *works* in most cases.

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

You mean like twisted.internet.iocpreactor.abstract.ConnectedSocket?  Have you even read this code?

> [snip more oblique allusions to various win32 APIs]

Frankly, I don't think you know what you're talking about.  If you know enough to make iocpreactor, or even win32eventreactor, work on Windows with SSL and GUI support, great, do that and contribute it, and we can discuss the patch.  If not, we're not going to break the *only* working, tested Windows reactor because you think one day it should be different.

>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.

If it's easy, feel free to do it :).

>By the way: serialport already works only with win32eventreactor.

That is correct, but hardly relevant.