[PEAK] Events Question: How bad of an idea is this?

[Phillip J. Eby]

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.