Re: [Boost-users] [signals] thread_safe_signals feature-complete

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-19 16:02:19

Gottlob Frege wrote:

> I think the strong guarantee is much more important.  If I say
> disconnect() I really don't expect calls after that.  The deadlock
> only happens when:
> 
> 1. signals are being processed in multiple threads and
> 2. slots are disconnecting each other
> 
> 1 is not what I was typically thinking wrt threaded signals - I was
> more thinking about connect/disconnect from multiple threads, but the
> signal would only ever happen on the same thread.  Maybe that's too
> narrow of a view on my part.
> 2. slots disconnecting each other is really rare/stupid
> 
 > So I say you make the *default* disconnect wait, and supply an
 > alternative for the rare cases.

I think avoiding potential deadlocks is equally important to the
strong disconnection guarantee. The most prominent aspect of
Signals is the decoupling between caller and callee it provides.
The signal knows nothing about the code it calls and - through
generalized callbacks - the called code doesn't even need to know
it is called by a signal. We cannot expect from a user that they
will carefully steer around potential deadlock problems as that
would defeat most of the advantages of using the system in the
first place. It's quite possible a user has no control at all
over the slot code, for example.

On a side note: I don't know if you've followed the tracking
functionality changes we've discussed. In a nutshell, we agreed
that shared_ptr/weak_ptr is the most portable, useful solution
in a multi-threaded environment. Since this kind of tracking
ensures the lifetime of the tracked objects during a slot call,
a weak disconnect would not keep users from safely releasing
resources associated with a slot - as long as they're tracked.

> P.S.  what about connect/disconnect 'pairing'?  ie is there an assumed
> (or explicit) contract that every call to connect is matched by a
> disconnect?  If I have a slot that is in a signal, and that SAME
> signal is triggered in, say, 3 threads, the slot can't just call
> disconnect() (ie the same code in each thread) - it has to somehow
> carefully keep track that it is calling disconnect() in 1 thread, and
> the other 2 threads need to skip the disconnect() call.
> 
> Or does that matching guarantee not exist?

I don't think I understood this. You can only connect a slot once -
if you connect it twice it will be a separate connection and the slot
will be called twice. You can only disconnect it once accordingly,
although trying to disconnect it several times won't do any harm.

Regards

Timmo Stange