[TransWarp] Stopping peak.running.scheduler.UntwistedReactor

Phillip J. Eby pje at telecommunity.com
Thu Jul 10 17:34:04 EDT 2003


At 11:58 PM 7/10/03 +0300, Yaroslav Samchuk wrote:
>Hello,
>
>I have an application, that uses peak.running.scheduler.UntwistedReactor. 
>There are some readers and writers registered in this reactor, but there 
>could be a situation, when no more readers, writer and laters left - so 
>there is nothing to proceed. And this is the point, reactor must be 
>terminated, I suppose...

How does it happen that you end up with no more readers or writers?  I'm 
curious, because in most circumstances, at least one reader will be some 
kind of server listening, so why would it be terminated?

For other types of applications, the IMainLoop component manages idle 
timeouts, so that if no useful work occurs for some time period, the 
reactor will be shut down.  IMainLoop can also shut down after a fixed 
interval, and can also ignore idle timeouts until some interval has passed.


>So, my question is - what is the correct way to stop 
>peak.running.scheduler.UntwistedReactor in the described situation? Is it 
>a bug or a feature, that reactor continue to work either in case of no 
>selectables (as well as laters) left?

To be honest, I had never considered such a possibility, as every 
application scenario I envisioned for using the reactor either has an 
explicit shutdown command occurring, is explicitly time-bound (periodic 
task runner), or is a "run forever" loop.  I am having trouble envisioning 
a reactor-driven app whose tasks just "fade away".  Maybe if you could 
describe your app in more detail...?


>My solution was to override this reactor and to check readers, writers and 
>laters on every iteration in reactor's run() method and if there are no 
>any of them I just say self.stop(). Is it a correct way to terminate 
>reactor in case of nothing to proceed or may be there is another way to do 
>it, but I don't see it?

Well, that's one way to do it.  I'd like to understand your intent better 
though, before recommending a PEAK idiom for doing this.




More information about the PEAK mailing list