On Apr 18, 2005, at 1:19 AM, glyph@divmod.com wrote:
On Sun, 17 Apr 2005 22:22:32 -0400, Itamar Shtull-Trauring
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