[PEAK] Anybody using reactors?

[Phillip J. Eby]

At 08:17 PM 1/14/04 +0200, alexander smishlajev wrote:
>>>we use it to handle timeouts: timeout procedure is registered with 
>>>callLater(), and we continue with normal data flow.  when expected event 
>>>arrives, timeout procedure (if any) is removed from the queue, with 
>>>possible resheduling at a later time.
>>Ah.  Okay, so something like:
>>while True:
>>     yield events.AnyOf(data.readable, scheduler.timeout(30)); 
>> src,evt=events.resume()
>>     if src is data.readable:
>>         # got something, act on it
>>     else:
>>         # timed out
>>would work, then?
>
>it seems so, at least at the first glance.

Good to know; I won't worry about such cancellations in peak.events, then, 
unless somebody else presents a different use case for cancelling/rescheduling.


>(i do not fully feel the event yelding mechanics yet, but i've already got 
>an impression that it must be much more cosy than our current state machines.)

So far, it seems to me the strength of peak.events is in managing events 
that happen in sequence, which is *very* hard to do clearly in a 
reactor-driven style.  OTOH, code for managing *parallel* events (such as 
"read data or timeout") tends to be a bit verbose in peak.events.

On the bright side, it is possible to reasonably compose and encapsulate 
the handling for repeated use.  For example, I could make a routine or 
method like:

def withTimeout(eventSource, sleep):

     while True:
         yield events.AnyOf(eventSource,sleep); src,evt=events.resume()

         if src is eventSource:
             # pass the event back to the caller
             yield evt; events.resume()
         else:
             raise TimeoutError

and then use it in my other routines:

     readOrTimeout = withTimeout(data.readable, scheduler.sleep(30))

     try:
         while True:
             yield readOrTimeout; events.resume()
             # ... got data, act on it

     except TimeoutError:
         # act on the timeout


(Note that the 'readOrTimeout' variable would no longer be usable once it 
throws the TimeoutError; it would be necessary to call 'withTimeout()' 
again to create a new generator.)

Anyway, the interesting thing about all this is that it's possible to build 
up complex structures in 'peak.events' using functional decomposition, 
which can be *very* hard to do in a callback-driven style.