[PEAK] StopIteration: Unexpected reactor exit

[Phillip J. Eby]

At 02:03 PM 3/25/04 -0800, John Landahl wrote:

>The diagram is grossly oversimplified for illustration purposes.  The 
>application is based on EventDriven, which uses its own 
>EventLoop.runUntil(), and func1 is called fairly deeply inside some code 
>run periodically by a Task.  By "nested" I meant that the runUntil calls 
>used within func2 are called within the already active runUntil in 
>EventDriven's MainLoop.
>
>   aTask (async) -> func1 (sync) -> func2 (sync) -> spawnProcess/PB (async)
>
>I thought that one could use a runUntil in such a situation, so that func2 
>could wait for the data from the async calls, use it for its own purposes, 
>and return something back to func1.  But you seem to be saying that a 
>completely different approach will be required.

Only because you're using Twisted for both levels of event loop.  PEAK 
allows you to have as many event loops as you like, but Twisted supports 
only one.


>   The problem is that func2 is only called occasionally by func1, so I 
> can't just pre-load the data from the spawnProcess and PB calls in a 
> separate async Task.

You'll have to make the synchronous functions asynchronous then.  What you 
do is take all the 100% synchronous parts (i.e. parts that *don't* call any 
asynchronous code), and farm them out to threads using 
reactor.deferToThread.  You'll then be left with a 100% asynchronous task.