RE: [boost] Signals Review

From: Soren Frank Andersen (sfa_at_[hidden])
Date: 2002-02-26 06:05:20

> -----Original Message-----
> From: Douglas Gregor [mailto:gregod_at_[hidden]]
> Sent: 25. februar 2002 22:58
>

...

> > 1) I believe the slots is signalled in the sequence defined
> >    by the SlotNameCompare function. But I could not find answers
> >    for the following questions?
> >    a) Is the signals with 'low' names called first?
> >
> >    b) What about unnamed connections or connections with the
> >       same name, are they signalled as first connected first
> >       signalled, last connected last signalled, or is the
> >       sequence undefined?
>
> The answer to these is intentionally left unspecified, but it deserves a
> comment in the tutorial: there are no guarantees about ordering of named
> connections with respect to each other, or between named and unnamed
> connections.

I believe it is important to specified the calling order. I had hoped
the connection name could be used for specifying this.

I often use signals for signalling that some thing needs to be updated.
The update sequence is important, because a sub optimal update may course
screen flicker, or worse one of the slots may have a side effect that
another slot depends on.
In my current signal library the calling sequence is last connected first
signalled. (this way slots that is connected while in a signal-loop is
not called).
But it is different to control the connection sequence, because
the connection points is often spread across the entire program.
Therefore I was hoping the named-connection system could help control
the calling order.

I would like if something like the following could be used to
ensure correct calling order.

class my_button {
public:
  typedef boost::signal0<
    void,
    boost::signal::last_value,  // Note this is why last_value
                                      // needs to be in the documentation
    int
    std::less< int >
  > click_signal_type;

  typedef click_signal_type::slot_type click_slot_type;

  enum signal_order { early = -10, normal = 0, late = 10 };

  boost::connection on_click_connect(
    const click_slot_type& s,
    signal_order n = normal
  ) {
    return on_click.connect(n, s);
  }

  private:
    click_signal_type on_click;
};

> > 3) What happens if you disconnect while in a signal-loop?
> >    Is it safe?
>
> This definately needs documentation, I'm just not sure how to
> document it well :(.
> In the single-threaded case, it is safe to disconnect at
> any time.
> So something like this is legal and safe:
>
> sig1 calls slotA
> slotA calls sig1
> sig1 calls slotB
> slotB deletes sig1

The above documentation is good enough for me. :-)

> > 7) I would like to have the Complexity of more functions documentated.
> >    It is surprising that the complexity of signal::empty()
> >    is O(n), where n is the number of slots in the signal.
> >    Maybe it would be better to have a signal::size() function.
>
> Okay. empty() can be written as a constant time operation, if an
> active slot
> count is added to a signal. Would you prefer that?

No, this is unimportant. I was just wondering if there were more
surprises. Note In our program we have some signals with more then 200
slots connected, so the complexity of the operations can be very important.
It would be bad if any operation was O(n*n).

One other thing. It may be a good idea to make the default slot name a int.
I don't know the slot implementation, but I think it will make the signal
more effective (memory and cpu). And I don't think named connections will be
used very often. And when they are, I will prefer a enum value.

Soren