[PEAK] problem with peak.io_events

[Phillip J. Eby]

At 04:54 PM 9/8/04 +0300, Vladimir Iliev wrote:
>class Comp(binding.Component):
>
>     def _setup(self):
>         def cb(*a): print 'cb:',a
>         ss = self.lookupComponent(ISignalSource)
>         ss.signals(tuple(signal_names)).addCallback(cb)
>         MyTask(self, runEvery=1)
>     _setup = binding.Make(_setup, uponAssembly=True)

This should say:

       ss.signals(*tuple(signals)).addCallback(cb)

because 'signals()' takes signal *names* as positional arguments.  You were 
passing a tuple of signal *numbers* as a single argument.

(The 'signal_names' dictionary maps numbers to names; the 'signals' 
dictionary maps names to numbers.  Converting a dictionary to a tuple uses 
the keys, so 'tuple(signal_names)' is a tuple of numbers, not names.)

The normal usage of the 'signals()' method is like this:

     source = ss.signals('SIG_SOMETHING', 'SIG_OTHER_THING', ...)

i.e., I expected people to normally use a set of constant signals.

One drawback to the current implementation is that it doesn't care if you 
give it unrecognized signal names, because it assumes those signals just 
don't exist on the current platform.  Thus, the tuple of signal numbers you 
passed in was being looked up in 'signals' and not found, and thus 
ignored.  The event source returned was just a null event source that never 
fires.