[PEAK] StopIteration: Unexpected reactor exit

[John Landahl]

On Thu, 25 Mar 2004 16:31:45 -0500, Phillip J. Eby <pje at telecommunity.com> 
wrote:

> At 01:11 PM 3/25/04 -0800, John Landahl wrote:
>
>>   func1   (synchronous)
>>     func2 (synchronous)
>>       reactor.spawnProcess (asynchronous)
>>       PB call (asynchronous)
>
> If what you just showed is *all* your program does, you wouldn't have 
> another event loop.  func2 would make two (non-nested) runUntil() calls, 
> and that would be that.
...
> So...  is func1 being called from the reactor, or is it a top-level 
> program?  If it's  called from the reactor, you have a synchrony 
> sandwich (sync code between two layers of async) and you have a problem.

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.  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.