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

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-02-19 14:37:56

On 2/19/07, Frank Mori Hess <fmhess_at_[hidden]> wrote:
>
> Yes, I think the strong disconnect() guarantee will also guarantee the
> deadlock you outlined earlier with two slots attempting to disconnect each
> other will always be possible.
>

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.

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?

- Tony