[PEAK] problem with peak.io_events
vlado at vintech.bg
Tue Sep 14 04:29:41 EDT 2004
Phillip J. Eby wrote:
> 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))
> 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.
> PEAK mailing list
> PEAK at eby-sarna.com
Now it works. Thanks!
More information about the PEAK