[PEAK] Reactor-driven microthreads

[Ulrich Eck]

> Regular threads are not the answer, though, as preemptive multitasking is 
> prone to far subtler bugs.  So, a co-operative multitasking mechanism is 
> needed.
> 
> Python generator functions provide an ideal basis for such a 
> mechanism.  Indeed, Twisted has its 'flow' package to do something similar 
> to what I have in mind.  However, even 'flow' has some "twisted" 
> assumptions that don't really suit PEAK.  Even in 'flow', the reactive 
> paradigm still seems quite central, and generators are used to make the 
> existing Twisted framework more usable in certain areas.
> 
> But, a lot of the things the Twisted framework offers, like protocols and 
> connectors and the like, are primarily necessary because Twisted is 
> event-driven in the first place!  If it were based on co-operative 
> multitasking, much of that complexity would go away.  Consider the relative 
> simplicity of:
> 
>      def talkToAServer(self,address):
> 
>          sock = self.lookupComponent(address, adaptTo=net.IClientAsyncSocket)
>          readline = sock.readline
> 
>          try:
>              yield sock.untilConnected(timeout=self.connTimeout)
>              yield sock.send("HELO world\n")
>              yield sock.untilLineRead(timeout=self.lineTimeout)
>              data = readline()
>              # do something with the data
> 
>          except sock.TimeoutError:
>              yield mthread.Error()
>              sock.close()
>              return
> 
>          sock.close()
> 
> Compared to most client code I've seen for Twisted, this is pretty darn simple.


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 ?


> So, maybe it could be 'coop.Thread', 'coop.Queue', etc., except those
> look 
> to me more like "coop" (as in chicken coop) than like co-op.  'multi'
> seems 
> too generic.  Remaining candidates:
> 
> task
> tasks
> tasking
> events
> 
> These are all pretty generic, though, and perhaps imply greater
> generality 
> than intended.  'events.Queue', 'events.Thread', and 'events.Sleep'
> all 
> read very nicely, although again they seem to give the package greater
> scope than originally intended.  That is, at some point PEAK is likely
> to 
> have various other kinds of "events" besides these.  OTOH, one of the
> main 
> candidates for other kinds of events is GUI support, and this kind of 
> "threading" is just as useful/relevant in such an environment.  
> Indeed, 
> anything that needs to respond to a sequence of "events" is likely to
> be 
> more easily expressed as a thread.
> 


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.

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.

just my 0.02$

Ulrich