[Twisted-Python] Foreign event loop friendly reactor
bob at redivi.com
Mon Apr 18 01:54:54 EDT 2005
On Apr 18, 2005, at 1:19 AM, glyph at divmod.com wrote:
> On Sun, 17 Apr 2005 22:22:32 -0400, Itamar Shtull-Trauring
> <itamar at itamarst.org> wrote:
>> On Sun, 2005-04-17 at 18:45 -0400, Bob Ippolito wrote:
>>> Forget everything you ever learned about wxPython/Twisted
>>> It is no longer relevant. Forget that any of the ugly
>>> Python Cookbook entries, lame wiki examples,
>>> twisted.internet.wxreactor, etc. even exist.
>> We should update the GUI event loop integration howto to point at the
>> new method, and deprecate wxsupport and wxreactor too, in that case.
> Why not just change wxreactor.install() to use this new code, rather
> than deprecating it? That would leave the door open to new strategies
> in case wx ever gets a non-broken eventloop.
I look at it this way:
- Using a thread for a socket event source isn't a bad idea (it's what
Qt/Cocoa/etc. are doing behind your back anyway), and can give us
options for even better performance on multi-core/multi-processor
machines when a foreign event loop is in control (i.e. reads and writes
could also happen in the thread).
- Writing wrappers for the socket/timer stuff in GUI frameworks sucks,
because they're often too different, limited, or buggy
- The implementations of socket wrappers and timers in GUI frameworks
are usually slow, incomplete, buggy, etc. (again).
- Not caring about GUI reactors lets you deprecate > 1300 lines of
reactor code in exchange for a couple examples and a short support
library or two that we should have anyway
- The reactor interface could be extended such that
threadedselectreactor goes away, and the select/kqueue/poll/epoll/iocp
reactors become compatible with interleave(), which lets all reactors
be compatible with foreign event loops while still maintaining the
choice to do whatever is teh smart for your platform.
More information about the Twisted-Python