[PEAK] Anybody using reactors?

[Phillip J. Eby]

At 08:47 PM 1/13/04 -0500, Bob Ippolito wrote:

>On Jan 13, 2004, at 8:25 PM, Phillip J. Eby wrote:
>
>>At 08:01 PM 1/13/04 -0500, Bob Ippolito wrote:
>>>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 :)

Um, see the part above where I said "additionally creating a 
running.IMainLoop that used reactor.run()".  :)


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

And it can't ever be run recursively?  Not that that's an issue if I do the 
workaround I described above, but it *is* an issue for programs that want 
control of their top-level loop for whatever reason, e.g. to force events 
to be processed until something happens in synchronous code.  I realize 
that in the Twisted world, there's no such thing as synchronous code, but 
for "application" code IMO it's better to nest asynchrony within synchrony, 
than to try to turn the entire system inside out to be 100% asynchronous.