[PEAK] A taxonomy of event sources: designing the events API

[Bob Ippolito]

On Jan 7, 2004, at 10:13 AM, Phillip J. Eby wrote:

> At 10:02 AM 1/7/04 -0500, Bob Ippolito wrote:
>
>> On Jan 7, 2004, at 9:42 AM, Phillip J. Eby wrote:
>>
>>> At 12:12 PM 1/7/04 +0100, Ulrich Eck wrote:
>>>> I'm really looking forward to rewrite my workflowstuff to use
>>>> peak.events .. it will fit perfectly i think :))
>>>
>>> Keep in mind that generators can't be pickled, so you really can't 
>>> use events.Thread objects to represent workflows that last longer 
>>> than a single program run.
>>
>> Stackless Python pickles generators! :)
>
> ...and IIRC, it does so by also pickling the code object involved, 
> which doesn't provide any opportunity for workflow process evolution.  
> That is, if you change the code, existing instances are unaffected.  
> For certain circumstances that's useful, for others it's not what you 
> want.  At least, it's not what I want as the primary mechanism for 
> saving state.

Well, here's an idea.. I'm not an expert on Communicating Sequential 
Processes, but maybe you should be before writing the events API.  It's 
the model that Christian Tismer has settled on for the next version of 
Stackless.  There's been a lot of discussion about it on the stackless 
list lately.  There's books and papers on CSP that are available free 
online, but I have not had time to read and absorb enough of it yet to 
talk confidently about it.

-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/20040107/3f42e1a8/smime.bin