[PEAK] StopIteration: Unexpected reactor exit

[Phillip J. Eby]

At 09:55 PM 3/24/04 -0800, John Landahl wrote:
>In a PEAK+Twisted app, StopIteration is being raised by 
>peak.events.twisted_support.EventLoop.run_until().  The particular 
>invocation of run_until() is the one called by MainLoop.run(), which means 
>that its reactor.run() finished before its exitCode fired an event.  There 
>are nested EventLoop.run_until() invocations in this scenario; one is a 
>wrapper around the deferred returned by a reactor.spawnProcess(), the 
>other around a PB call's deferred.  Shortly after these run and finish 
>successfully, another reactor.spawnProcess() is called; *immediately* 
>after yielding to the deferred from this spawnProcess(), the reactor's 
>main loop terminates, resulting in the StopIteration from the original 
>runUntil().  If I comment out both of the nested runUntil() invocations, 
>no StopIteration occurs.

I'm having a little trouble following you, but the main thing I'm getting 
is that you have nested event loops.  Twisted doesn't like that.  :)


>I seem to recall that ServiceAreas were added partly to get around some of 
>the ugliness caused by Twisted's singleton reactor.  I've tried turning 
>the component which calls the inner runUntils into a ServiceArea with its 
>own reactor (via binding.Make(running.ITwistedReactor, 
>offerAs=[running.ITwistedReactor]), for good measure), but this doesn't help.

That's because Twisted insists on having only one reactor.  If you want 
more than one (and if you have nested event loops, then you do), all but 
one have to be "untwisted".


>I know this isn't much to go on, but perhaps it's just something simple 
>I've overlooked...

It may be that nested event loops aren't what you actually want or 
need.  You should only need a nested event loop if you have *synchronous* 
code that is sandwiched between an asynchronous caller and an asynchronous 
callee.  If you can make that synchronous code asynchronous, the need for a 
nested event loop goes away.