glyph@divmod.com wrote:
On 01:39 pm, itamar@itamarst.org wrote:
On Fri, 2008-03-28 at 06:23 +0000, James Mansion wrote:
Shouldn't broken Win32 implementations be 'retired'?
These implementations aren't "broken", so much as "limited".
Well, if they don't honour what the documentation says, then they seem broken to me, and the documentation doesn't say you might get an unexpected 64 connection limit. No matter.
Please feel free to contribute patches which reduce these limitations.
The old I/O Completion Ports reactor (which should be most scalable Win32 reactor) was somewhat buggy. Twisted 8.0, released this week, has a complete rewrite that hopefully is a lot better.
It still doesn't support SSL, though:
Need something patterned very much like Len's stuff here http://www.lenholgate.com/archives/000456.html I guess.
and maybe some other features too (I don't have a Windows handy or the time required to read the code to check - this really ought to be better-documented).
The select reactor is also convenient for testing on Windows, because it's the basis of at least one GUI reactor (GTK+) which should also support Win32.
Your suggestion for handle buckets in the win32eventreactor is one which has been suggested before and sounds good to me. Nobody has bothered to implement it yet :). However, even in its absence, I don't believe we'll be completely dropping win32eventreactor because it is useful for integrating with programs that do win32 drawing, even if iocpreactor has higher performance and is more scalable. Well, you need a daemon worker thread to call GetQueuedCompletionStatus(Ex) and enqueue the results to the main thread, but that daemon worker doesn't even need to have the full support of the C library multithreading so long as it just swizzles pointers and calls raw API routines. Its normally more of a gotcha that you might try to submit IO from a pool thread that might reasonably be terminated before the IO completes. Why do you need an event reactor to support win32 applications, except to call MsgWait... rather than GetQueuedCompletionStatus?
On a similar sort of topic - is there a reason to have lots of implementations for POSIX, rather than use libevent or libev? James