[Twisted-Python] Foreign event loop friendly reactor

[Bob Ippolito]

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 
>>> integration.
>>> It is no longer relevant.  Forget that any of the ugly 
>>> wxPython+Twisted
>>> 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.

-bob