[PEAK] Reactor-driven microthreads

[Phillip J. Eby]

At 07:10 PM 1/2/04 +0100, Ulrich Eck wrote:

>looks good .. i've implemented a simpler but similar module for my WFMC
>WorkflowEngine Prototype i developed using Transwarp. i think this way
>of chaining calls and still remain concurrency is much easier than
>the use of twisted.deferreds as it does not require to create that many
>methods. one drawback is, that many api-methods end up in returning
>iteraters others won't .. will this complicate the use of peak ?

No.  Take a look at peak.events.interfaces.  You'll notice that as of the 
current draft, event sources are a special case of something you can task 
switch on.  That doesn't mean that everything turns into iterators.  I 
don't want to replace Twisted with another framework that forces everything 
to be changed to fit.  :)

So, you'll be able to completely ignore the threading facilities if you 
don't need/use them.


>i think of an event as it is described in UML StateMachine. Some
>Happening of an Action that triggers one/more transitions of a
>statemachine.

Yep.


>thus i don't really like to see thinks like Task, Scheduler, Threads
>in an events package. If you plan to extend the events framework with
>some EventService that manages subscription to event-sources and
>implements several distribution strategies (round-robin, multicast, ..)
>i would like to see a peak.events package only for this domain.
>
>if you not tend to extend the functionality related to events i'ld
>prefer to call the new framework task* or include it into the current
>running package.

Take a look at the draft interfaces and implementation.  You'll notice that 
there are only a couple of things that deal specifically with microthreads; 
most of what's there so far really *is* about events.

The basic idea is an "event source": something you can add callbacks or 
subscribe to.  The simplest kind of event source is just a trigger that you 
can "fire", activating the callbacks.  Then, there is the concept of a 
"value", which is a variable you can get or set, and when it is set, the 
callbacks are fired.  Next is a "state", which is like a value but it only 
fires if the value is *changed*, as opposed to merely set.  Then there are 
"queues", which fire callbacks when data is put into them or when there are 
readers waiting and the queue is empty.

Based on these and other similar objects not yet implemented, you can do 
callback-style event programming, as well as threaded-style event 
programming.  So, the way things worked out, the "Thread" class is actually 
only a tiny piece of the events framework, even though 'IEventSource' 
derives from 'ITaskSwitch'.  Note, however, that this means that any event 
source you create using the events framework, is immediately usable as 
something that a thread can suspend itself on and "wait" for.  (i.e. be 
resumed the next time the event occurs.)

I intend these event types to be usable for GUI programming too: one could 
have GUI output widgets depend on (and update) Value or State objects, and 
buttons or menus could fire simple trigger events.  This would be a nice 
way to set up event-driven application code, without "buying in" to a 
single GUI package's event framework.  Just set up IEventSource (or 
whatever) adapters for tht GUI package's types, as relevant.

As soon as these things occurred to me, I realized that although the 
threading idea is important, it's not really central to the need or use of 
event handling in PEAK.  And, I've been rewriting "subscribe to some kind 
of event" code a lot lately.  :)