[PEAK] Anybody using reactors?

[Bob Ippolito]

On Jan 13, 2004, at 8:25 PM, Phillip J. Eby wrote:

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

I don't know exactly what you mean by all this, but I do know it won't 
work with the OS X reactor, because it needs run/stop :)  I could 
rewrite it so that it revolved around usage of iterate(), but the 
typical use case is that your network application starts *after* the 
GUI runloop does, so iterate() wouldn't exactly be compatible (since 
the GUI runloop has already started, and you're *in* a callback from 
it, you can't really iterate it) which complicates that significantly.  
Basically, OS X has its own written-in-C reactor that GUI Python (well, 
PyObjC) applications are running in and should yield to *it*, not vice 
versa.

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20040113/d4ba3f31/smime.bin