[PEAK] Reactor-driven microthreads

[Bob Ippolito]

On Jan 2, 2004, at 1:10 PM, Ulrich Eck wrote:

>> 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 ?

The way I've done it is to wrap the methods themselves with descriptors 
that take a (particular style of) generator and return a deferred.  
That's the way it really needs to be done in order to be useful at all 
(though the detail of when/how the wrapping happens could be changed).

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20040102/b3cda373/smime.bin