[PEAK] EventDriven, ITwistedReactor, and AdaptiveTask daemons

[Phillip J. Eby]

At 08:16 PM 1/5/04 -0800, John Landahl wrote:
>On Mon, 05 Jan 2004 21:23:10 -0500, Phillip J. Eby <pje at telecommunity.com> 
>wrote:
>
>>Alternatively, if your application runs from an .ini file, you can add this:
>>
>>[Component Factories]
>>peak.running.interfaces.IBasicReactor = 'peak.running.scheduler.getTwisted'
>
>That's quite nice.  I've been wondering about how functions or methods 
>(rather than classes) might work with [Component Factories]...

To be used as a "global" service (i.e. have a default instance covering the 
current service area), a component factory must be callable with zero 
arguments.  To be used with e.g. 'binding.Make(IWhatever)', it must be 
adaptable to binding.IRecipe, which means it can be a callable with 0, 1, 
or 3 arguments.  If it takes one argument, it'll be passed the 'self' of 
the object whose Make it is, and if it takes three, it'll be passed 
'self,instDict,attrName'.

In practice, classes or types adapted to IRecipe are wrapped as 
zero-argument functions, so the argument count only matters for functions.

Finally, you can also use [Component Factories] just to register things to 
look up via 'config.FactoryFor(IWhatever)', e.g.:

      _makeFoo = binding.Obtain(config.FactoryFor(IFoo))

      def newFoo(self, ...):
          return self._makeFoo(...)

So for this usage, the arguments can be whatever you want.  It's just that 
the factory had better have defaults for all its arguments if you will also 
want a "global" (area-wide?) IFoo.


>>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".
>
>Can't wait.  peak.events sounds like one of the most exciting new 
>developments in Python...

Heh.  That might be a *little* overstated.  :)  Generator-based 
microthreads have been possible  ever since Python 2.2 was released, and 
there have been articles out there for a while on how to do them.  (E.g. 
David Mertz' coroutines and microthreads articles.)  And Twisted has its 
own version of the same concept.  So, this is at best a refinement of 
already groundbreaking work by other people.

The principal refinements that I'm adding are:

* Semi-transparent error propagation
* Semi-transparent data transfer *into* a running generator
* "Untwisting" the event-driven system as a whole, so that you don't have 
to have a reactor at the center of the universe

The latter item also means that in peak.net, protocol management won't 
force you to e.g. subclass LineReceiver in order to do the equivalent of 
'.readline()' on a socket.  IOW, you'll be able to *use* protocol 
components, rather than always having to *be* a protocol component, if you 
see what I mean.