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
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
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
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
glyph@divmod.com wrote: there's no point living a fantasy. I do need to understand how limited the current implementation is though. formation during design. I know its quite common in open source. :-( thread, but that shouldn't preclude restarting incomplete writes or doing low-level protocol stuff in a thread. 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.