[PEAK] problem with peak.io_events

[Phillip J. Eby]

At 06:50 PM 9/13/04 +0300, Vladimir Iliev wrote:
>Phillip J. Eby wrote:
>
>>What OS are you using?
>I tried on both Fedora Core 1 (python 2.3.4) and Gentoo (python 2.3.4).

Hm.  On Python 2.3.3 and Red Hat 6.2, it works with or without the 
itertools import.  On Python 2.2.3, I can't get it to work at all, unless I 
fix another bug in your script, that I didn't notice previously.

'ss.signals()' returns an event object that is only valid for as long as a 
reference to it is held.  The routine that calls it discards the reference 
when it returns, so perhaps you're seeing some sort of GC irregularity when 
you import itertools.  (There was a change to how GC at shutdown works in 
Python 2.3.4.)  The following code works for me:

class Comp(binding.Component):

     def _setup(self):
         def cb(*a): print 'bzzzzzzzzzzzzz'
         ss = self.lookupComponent(ISignalSource)
         ev = ss.signals(*tuple(signals))
         ev.addCallback(cb)
         MyTask(self, runEvery=1)
         return ev   # save a reference to the event object
     _setup = binding.Make(_setup, uponAssembly=True)


I'm considering changing this aspect of certain peak.events, so that they 
remain valid whenever they have callbacks, rather than requiring a 
reference to be held at all times.  But it may be a while before I can get 
to that.  In the meantime, whenever you request dynamic I/O events like 
'readable()' or 'signals()', you should hold onto the event for as long as 
you'd like to receive callbacks.