[Twisted-Python] win32 reactors

[James Mansion]

glyph at divmod.com wrote:
> Patches which rectify this situation for any reactor, either from the 
> perspective of docs or code, would of course be appreciated.
There's no point giving a commitment to doing more than discussing 
implementation approaches. With the
best will in the world its unlikely to get to the top of my pile and 
there's no point living a fantasy.

I do need to understand how limited the current implementation is though.

> And, if you're going to file a ticket, be prepared to actually follow 
> up with an implementation.
Hmm - that's a crap attitude unless you want to deter any concensus 
formation during design.
I know its quite common in open source. :-(
>   While we want to maintain support for Windows, the level of energy 
> for doing really interesting Windows-specific stuff in Twisted is, in 
> a word, "low".
>
> One thing you might want to know before you file that ticket is that 
> *if* there's a reason for the way things are now, it's because in the 
> Twisted idiom we always make sure GUI stuff and network stuff is 
> happening in the same thread.  If one of the approaches that you 
> mentioned requires a dedicated "network" application thread, then 
> that's probably why we aren't doing it.
I appreciate that a reactive system will generally want to run its 
completion callbacks in the main
thread, but that shouldn't preclude restarting incomplete writes or 
doing low-level protocol
stuff in a thread.
>> On a similar sort of topic - is there a reason to have lots of 
>> implementations for POSIX, rather than use libevent or libev?
>
> There is more than one answer to this question.  Maybe someone will be 
> helpful and turn some of these answers into a FAQ on the wiki:
>
> 1) Twisted predates libevent by a few years and libev by many years. 
> One might instead ask why libevent didn't help us develop a C reactor, 
> rather than writing a whole new library.
I've no idea, but if you have a separation of a support library with an 
abstraction that one might
expose with SWIG or similar and reuse directly from C(++) - then this is 
well not actually apparent
on the web site. I think it would be a good idea though,and its more 
likely that I'd be able to
contribute something of this sort (eventually) than anything 
Python-specific.

You have a nice model and one that is much more portable than the common 
reactor idiom.

> 5) Despite many valid rationalizations for its existence, the code in 
> Twisted was developed organically over many years.  The stuff you'll 
> find here is the stuff that people thought was interesting and had 
> time to work on.  Strategically standardizing on a single low-level 
> multiplexing mechanism is not something that is particularly fun or 
> rewarding, especially when getting rid of the old code removes value 
> for some users.  (Not everyone already has libevent installed.)
The curse of volunteer-ware, I guess.  Understandable, but a shame in 
some ways.