[PEAK] Anybody using reactors?

[alexander smishlajev]

Phillip J. Eby wrote, at 14.01.2004 20:42:

>>> 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 found one slightly different case, although it is implemented without 
removeLater (we didn't have such beast at that time).  when a running 
task is suspended by another task, it shedules an operator warning to be 
iisued after some time; when the task is resumed, the warning is 
disabled (warning procedure is still run, but does not produce the message).

it seems to me that this case also may be handled with

   yeld events.AnyOf(appEvents.resume, scheduler.timeout())

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

i wouldn't say it was that hard.  here's reactor callback of one of the 
most complicated components:

     def doWork(self, job):
         """Called by reactor"""
         if job & self.TIMEOUT_FLAG:
             self.timeoutHandler()
         if job & self.DATA_FLAG:
             self.state()
         return True

where 'self.timeoutHandler' and 'self.state' are pointers to methods 
handling respectively timeout and data in current machine state, changed 
when machine state changes.  each of these methods does pretty 
sequential job.

(you may wonder why it is done by getWork/doWork, and not by doRead. 
that's because pipes between application components are not select()able 
on windows platform.)

best wishes,
alex.