[Twisted-Python] Re: Other ways to integrate foreign event loops?

[Glenn H Tarbox, PhD]

The Qt reactor, http://code.tarbox.org/qtreactor, inverts the
"ownership" of the callback loop as well.  However, Qt provides well
behaved callbacks for timers as well as socket activity so the reactor
behaves properly.  

The qt reactor design allows for the conventional reactor.run() at the
end of the script as well as a call to reactor.runReturn() which starts
up the reactor, nails up the timers and socket IO but returns to the
calling application.  Hence, you can startup twisted sometime after your
gui app is running.  Obviously, you need to "behave" properly and make
sure that any user code doesn't hang onto the thread but this is
required for proper gui handling code anyway...

Twisted's current wx reactor uses another thread due to difficulties
experienced with an earlier version of wx not behaving well.  There are
complexities WRT integrating those threads which lie at the heart of the
testing failures for the current wx reactor.  It might be easy to fix...

However, I've been thinking about taking the qtreactor approach and (re)
trying to fix the wx reactor by first evaluating whether wx is "better
behaved".  If it isn't, perhaps its straightforward to fix wx (???)

Thing is, once you get the logic down... and (I think) its all correct
in the qtreactor, it should be straightforward to use the wx calls to
get servicing for timing and socket IO.

-glenn


On Thu, 2008-04-03 at 17:35 -0500, Jean-Paul Calderone wrote:
> On Thu, 03 Apr 2008 15:35:36 -0400, David Bolen <db3l.net at gmail.com> wrote:
> > [snip]
> >
> >In our case, with wxPython based applications, things worked great
> >just having wxPython handle a timer that triggered reactor iterations.
> >It involved:
> >
> >* During initialization, start reactor with reactor.startRunning()
> >* At some periodic frequency, run reactor.iterate(0)
> >* During termination, set up a reactor.callLater for reactor.stop, and
> >  then call reactor.mainLoop().  This was the cleanest way we found to
> >  permit all reactor finalization (events, final I/O, etc...).
> >
> >Note that the first point violates the IReactorCore interface
> 
> Let me emphasize this.  The above relies on implementation details and may
> be broken by any subsequent release (assuming it works now, which I won't
> comment on).
> 
> Jean-Paul
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- 
Glenn H. Tarbox, PhD    | Don’t worry about people stealing your ideas. If your ideas
206-494-0819            | are any good, you’ll have to ram them down people’s throats
glenn at tarbox.org (gtalk) + ghtdak on aim/freenode     | ^ Howard Aiken, IBM engineer