[PEAK] Events Question: How bad of an idea is this?
chad at idrankwhat.net
Thu Nov 11 01:07:46 EST 2004
Makes sense. Thanks for the info!
On Wed, 10 Nov 2004, Phillip J. Eby wrote:
> At 05:50 PM 11/10/04 -0800, Chad Rosenberg wrote:
> >On Wed, 10 Nov 2004, Phillip J. Eby wrote:
> > > >With this change the above sample code runs to completion without any
> > > >errors, as does the code I am working with. I'm not sure of what, if any,
> > > >long term repercussion this may produce (stack overflows, infinite loops,
> > > >etc). Hence my question, how bad of an idea is this?
> > >
> > > Hm. Well, that depends on what you're doing with the Twisted side of
> > > things. Keep in mind that when you use a nested 'runUntil()', the reactor
> > > is going to fire shutdown events as soon as the *inner* runUntil()
> > > finishes. This may not be what you want, since I believe that it will
> > > close all current socket connections. Personally, I don't think that this
> > > would be a useful feature to add to PEAK. :)
> >Hmm, that didn't come up. I just added a simple echo server to my sample
> >code and Twisted 1.2.0 maintained all open socket connections throughout
> >all the eventLoop calls.
> Interesting. [quick break to do some research] Ah, I see. PEAK is using
> 'reactor.crash()', specifically to avoid this issue. I forgot I already
> dealt with that. :)
> It *does*, however, fire the 'startup' event each time you enter
> 'runUntil()'. Whether this has any potential negative effects on other
> parts of Twisted, I couldn't say.
> Personally, though, I'm not inclined to change the way the PEAK event loop
> works without hearing from somebody more knowledgeable about the full
> spectrum of Twisted reactors. The last time this was discussed, I seem to
> recall Bob Ippolito warning about the dangers of using nested reactor.run()
> on certain platforms.
> I should make it clearer, though, that runUntil() will not be changed in
> the way that you did, even if it's changed to better support a nested
> runloop in Twisted. The intent is that an error *should* be raised if the
> reactor exits unexpectedly, because it's not supposed to exit unexpectedly. :)
> Right now, nested runUntil() is *not* supported by PEAK for a Twisted
> reactor, so the current behavior is "correct" within its own narrow
> worldview, because it doesn't "expect" the loop to exit because an inner
> loop exited. However, if we *do* later support such a nested run loop,
> then it will be changed in some way such that it *will* "expect" the exit,
> or such that it does not exit.
> For example, the Twisted version of 'runUntil()' could save
> 'reactor.running' before the start of the loop, and use a try/finally to
> 'startRunning()' the reactor again before returning, so that the outer loop
> will not be exited just because the inner loop was exited. This would be
> the "correct" way, IMO, to support a nested run loop in Twisted -- assuming
> that Twisted actually supports it, which I currently doubt.
More information about the PEAK