Re: [boost] signals questions

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-10-30 10:10:23

On Tuesday 29 October 2002 12:16 am, David Abrahams wrote:
> > Perhaps this would be better:
[snip]
> Better. I think you should say how first and last are formed,
> though. It's not just _any_ old slot_call_iterator range, after all.

Okay.

> > > The last sentence in the "pass slot to disconnect" section is a major
> > > run-on. I'm having trouble figuring out what it's supposed to mean.
> >
> > Woah! Do I get an award for that sentence? It's astoundingly horrible.
>
> Can you clarify it for me?

The "pass slot to disconnect" mechanism assumings you can write code like 
this:
  sig.connect(bind(&Foo::bar, &foo, _1, _2));
  // ...
  sig.disconnect(bind(&Foo::bar, &foo, _1, _2));

To implement this means that we have to be able to compare arbitrary function 
objects. We can't.

> > > I'm still wondering, after reading the docs, whether it's OK to send a
> > > signal which ultimately destroys the signal itself.
> >
> > Yes, that's fine. Signals can be used recursively (signal A calls
> > slot B calls signal A) and can be deleted from within a slot they
> > call (signal A calls slot B, slot B deletes signal A).
>
> What are the precise semantics of these sorts of interactions? Does
> the current call to the signal complete if it is deleted during a
> notification?

The current call to the signal will complete.

> Is there any special interaction with the Combiner?

With 1.29.0, the combiner disappears when the signal disappears, so the 
interaction would be bad. This will be changing in CVS soon (the Combiner 
will persist so long as calls are being made).

> What if a slot is deleted during a notification? I think the latter is
> covered by the whole visit_each thing, but now I've forgotten; I need
> to review.

Slots can disconnected and/or their trackable objects can be deleted (causing 
the associated slots to be disconnected) at any time. A disconnected slot 
will not be invoked.

        Doug