[PEAK] EventDriven, ITwistedReactor, and AdaptiveTask daemons

[Phillip J. Eby]

At 04:10 PM 1/5/04 -0800, John Landahl wrote:
>The following chain of events seems to make it impossible to use the 
>Twisted reactor alongside AdaptiveTask-based daemons in an 
>EventDriven-based PEAK app: AdaptiveTask has an assembly event 
>(__addToQueue) which calls TaskQueue.addTask(), which calls 
>TaskQueue._scheduleProcessing(), which accesses its 'reactor' property, 
>which will get an IBasicReactor by default.
>
>My application runs from within a subclass of EventDriven which has an 
>assembly event that sets up an ITwistedReactor and offers it as 
>IBasicReactor.  AdaptiveTask.__addToQueue seems to get called before my 
>EventDriven subclass's assembly event, resulting in IBasicReactor being 
>used before the Twisted reactor can be setup.  This of course means that 
>the attempt to create the Twisted reactor will cause an error when it 
>actually does run.
>
>Is this the right way to go about things and something needs to be fixed, 
>or is there a better way to install a Twisted reactor in an EventDriven app?


For a quick fix, add this to your EventDriven subclass:

     tasks = binding.Make(running.ITaskQueue, offerAs=[running.ITaskQueue])

This will make a private task queue for your app, and it will use your app 
as the location to find an IBasicReactor.

Alternatively, if your application runs from an .ini file, you can add this:

[Component Factories]
peak.running.interfaces.IBasicReactor = 'peak.running.scheduler.getTwisted'

to make all requests for an IBasicReactor be satisfied by a Twisted reactor.

When peak.events lands, I hope to actually make Twisted interopability a 
bit cleaner.  Right now, a lot of configuration issues arise from the 
Twisted reactor design assuming a singleton reactor.  When PEAK itself no 
longer needs a reactor, it won't have to worry about which one is the right 
one to use any more, because it'll be possible to run as many as you want 
out of a given "scheduler".