[Twisted-Python] win32 reactors
james at mansionfamily.plus.com
Tue Apr 1 01:37:42 EDT 2008
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
You have a nice model and one that is much more portable than the common
> 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
More information about the Twisted-Python