[PEAK] problem with peak.io_events
Phillip J. Eby
pje at telecommunity.com
Mon Sep 13 12:10:50 EDT 2004
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:
def cb(*a): print 'bzzzzzzzzzzzzz'
ss = self.lookupComponent(ISignalSource)
ev = ss.signals(*tuple(signals))
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.
More information about the PEAK