[PEAK] Anybody using reactors?

[Phillip J. Eby]

At 08:01 PM 1/13/04 -0500, Bob Ippolito wrote:
>On Jan 13, 2004, at 7:54 PM, Phillip J. Eby wrote:
>>Most obvious of these is that if you're using a Twisted reactor, there 
>>will need to be a way to make it continue to run 'iterate()' 
>>operations.  A side-effect of this is that the reactor's 'run()' method 
>>will never be called, which means that Twisted startup/shutdown events 
>>will not run.  Is anybody relying on those events?  Even if you're *not* 
>>using a Twisted reactor, are you relying on the value of 
>>'reactor.running' anywhere?  Do you ever call 'reactor.run()'?
>
>I don't use PEAK events and Twisted together for anything at the moment, 
>but this is a Very Bad Thing to propose... it basically turns any Twisted 
>reactor into a polling reactor, the performance will suck,

That would only be true for reactors that don't already call iterate() in a 
loop, and I'm under the impression that most reactors do this.  Note that 
we'd be calling 'iterate(scheduler.time_available())', so as to allow the 
select operation (or external event loop) to run for the full available 
timeslice until the next action scheduled for peak.events.  Therefore, 
AFAICT, performance should be unchanged for reactors that currently call 
iterate() in a loop.


>and it won't integrate very nicely with some GUI frameworks (especially OS 
>X, because iterate basically starts up the runloop and shuts it down with 
>a callLater.. it's only there because the tests use iterate all over the 
>place instead of run/stop).

That seems a bit more problematic, although it could be worked around by 
additionally creating a running.IMainLoop that used reactor.run(), and an 
events.IScheduler that used reactor.callLater.  However, these would all be 
"non-default" implementations of those components as far as PEAK was 
concerned, and would require more [Component Factories] configuration to 
use.  But they would then be compatible with any Twisted reactors.  I'm not 
sure how much effort I want to put into supporting that, since PEAK 
frameworks are never going to depend on Twisted being installed, in order 
to run.  That makes it difficult for them to remain tested in the absence 
of Twisted.

OTOH, I suppose I could leave IBasicReactor and UntwistedReactor around, 
and use them to test the reactor-driven IScheduler, IMainLoop, and 
ISelector.  But I'd still prefer to phase them out for direct use in PEAK 
itself.  I guess in a4 they could move into the test suite, and out of the 
main code, so you wouldn't be able to use a reactor in PEAK 0.5a4 unless 
you were also using Twisted, or were willing to jump through some hoops to 
use the code stashed away in the test suite.