[PEAK] Events and listeners

[Phillip J. Eby]

At 03:03 PM 1/5/04 -0600, darryl wrote:
>I see peak.events are in cvs. Is there anything usable yet?

I'd suggest not playing with it yet; there are some significant 
refactorings still to come, as soon as I have time.  I don't expect to have 
time for a couple of weeks though.  :(

The main things on the table are:

* Getting rid of Queue

* Using the '(source,event)' callback API signature

* IClock -> IScheduler

* Dissociating threads from IScheduler, allowing them to run whenever they 
receive an event callback

* Getting rid of the ISubscription concept

* Separating shouldSuspend(thread) into shouldSuspend and suspendThread (so 
that aggregates like calculated values and AnyOf can delegate the test to 
their dependencies, but perform the actual suspension themselves

* Creating aggregates like AnyOf, Condition, etc.

* Making it possible to pass values *into* a thread, so that you can do 
things like:

   yield aSocket.readline(); line = resume()

in order to do a task-switching form of 'line = aSocket.readline()'.



>Also is the idea that peak.events are like 'weightless'(1) threads?
>
>-darryl
>
>(1) http://www-106.ibm.com/developerworks/linux/library/l-pythrd.html

peak.events will include a microthread implementation, yes.  However, it's 
only part of the overall concept.  The overall concept is to have standard 
interfaces for event-driven mechanisms like callbacks, listeners, handlers, 
and the like.  These are generally useful capabilities for event-driven 
programming including GUIs and network programming, whether you use the 
thread mechanism or not.

I do, however, expect that the microthread capability will eventually 
replace reactor-driven code in PEAK frameworks and tools.  This evolution 
will take place gradually, since I now have production code that depends on 
the "supervisor" tool and the reactor-driven FastCGI stuff 
(commands.CGICommand, etc.).

I think that in the long run, it will be a lot easier to write networking 
client code using the microthread style, than the reactor-driven callback 
style.  However, for continued compatibility with Twisted, I intend to 
include an ability to hook Twisted's reactor in as though it were another 
"thread".

One of the many things I'm excited about in the new peak.events 
architecture is that it is more decentralized than the reactor-driven 
style.  Notably, the same component need not be responsible for both time 
scheduling and I/O, which means that I/O management would be more pluggable 
via [Component Factories], so you could use e.g. a "poll" reactor instead 
of a "select" one for a special purpose.  In fact, one should be able to 
use events.Thread objects without having a central scheduler at all, if one 
has special needs.  (In practice, though, I expect most apps to use a 
single global scheduler.)