glyph@divmod.com ha scritto:
On Sat, 30 Sep 2006 01:01:06 +0200, Manlio Perillo <manlio_perillo@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