Re: [gtk-list] Re: Signals in Gtk+

[Tim Janik <timj gtk org>]

On 12 Sep 1998, Sascha Ziemann wrote:

> Owen Taylor <otaylor@redhat.com> writes:
> 
> | > I need attributed signals. By this a widget would be able to say "yes
> | > I want the timer signal, but only those running with 40 Hz".
> 
> |  gtk_signal_connect (GTK_OBJECT (forty_hz_timer), "expired",
> |                      callback1, widget_a);
> | 
> |  gtk_signal_connect (GTK_OBJECT (fifty_hz_timer), "expired",
> |                      callback2, widget_b);
> 
> I had something like this in mind:
> 
>   gtk_message_connect (GTK_OBJECT (widget_a), "clock", timer1, 40,
>                        callback1);
>   gtk_message_connect (GTK_OBJECT (widget_b), "clock", timer1, 50,
>                        callback2);
> 
> This is not a signal any longer, but a message, because the client
> reacts only on the signal, if the source (timer1) and the attribute
> (Hz) matches.
> 
> But I am not sure if it makes sense to use signals for timer events,
> because I do not know the overhead for a signal.

signal emissions usually involve about 3 function calls and four linked list
lookups. two of the ll lookups walk an object's data list which contains
about 1 or 2 nodes on average for widgets and is mostly empty for pure
objects. the other two ll lookups are used to walk the signal connections
of an object, so they increase with the amount of handlers you connect
to an object. if you use gtk_signal_emit_by_name() instead of gtk_signal_emit()
you get the extra overhead of string hash lookup, but this can usually be
avoided by storing the signal id upon signal creation or from
gtk_signal_lookup().
an extra optimization is made for objects without any handler connections,
the ll lookups will be skipped in this case.
in general, systems that are used for (quasi-) realtime processing are
usually fast enough (133Mhz and more) to not be affected by signal
emissions if used at reasonable frequencies (i.e. 500Hz and less).
since you use system calls like select() or alarm() for your timers
anyways, the highest accuracy to gain is 20ms or 50Hz on intel and
10ms or 100Hz on alpha, iirc. 

> An alternative can
> be:
> 
> - writing a timer object
> - the timer object does a gtk_input_add for the clock process
> - the timer object has a `define' function to set the timeouts
> - the timer object has a 'connect' function to register callbacks
>   for the different timer events
> 
> What I tried to avoid is defining a new callback register function,
> which possibly does not fit very well into the rest of the callback
> stuff.
> 
> | Or are you saying you want a single object to generate both
> | 40Hz and 50Hz signals?
> 
> Yes. When I use different objects for each timer, I have to put them
> into a timer group, because they need to be synchronised.

this should be pretty easy to implement through the class structure
of your objects. it just needs to fiddle which object needs to be used
for the emissions next.

---
ciaoTJ