Frank Mori Hess wrote:
But what if someone creates a large number of short-lived connections and relies entirely on our new automatic connection management scheme, never explicitly calling disconnect()? If the signal is only rarely invoked, the number of dangling connections with invalid weak_ptrs will accumulate, unless you check for them in connect().
Good point. I generally do not like garbage collection behaviour, but it seems unavoidable here. A specialized smart pointer could allow for direct notification when an object goes out of scope, but that would again have the effect that all of the code has to be aware of the trackability (either through intrusive_ptr and a trackable base class again, or through direct use of a pointer type for exclusive use in the signals system).
It's not late at all. I'm not committed to basing a full implementation on my code. I thought it would be a useful working prototype for exploring ideas while trying to clarify design issues. Whether it ultimately makes more sense to do the full implementation starting from boost.signals, or to try and graft the missing pieces from boost.signals onto the prototype is an open question.
I took Boost.Signals, removed grouping, naming and tracking (which are together responsible for more than half of the code) and added rudimentary threading support with a single recursive_mutex. I didn't want to spam the list with several kB of compressed code, so I put it here: http://www.sepulchrum.com/sources/mt_signals.tar.gz I kept the respective namespaces and hope that doesn't pose a problem for testing. What may be interesting to look at is that it works without dangling connections at all. A disconnected slot is always re- moved from the signal as soon as possible. That also simplifies the overall code, but doesn't solve the problem you describe above. The signal cannot be called concurrently with this design, as I've claimed before would be desirable, but I realized that it is complicated with non-trivial combiners anyway. Regards Timmo Stange