On Monday 05 February 2007 12:49 pm, Timmo Stange wrote:
Frank Mori Hess wrote:
There's also the matter of what happens in a combiner if a slot it hasn't reached yet is disconnected while it is running, which also will affect EPG::signal since it allows disconnect to happen during signal invocation, as long as the particular slot in question is not running. I was planning to make the slot iterator dereference operation throw an exception if the slot has been disconnected.
I'm not sure I understood this correctly. It should be ok for the client to disconnect slots that already have been called or will be called from an invocation context. That's what you have the ordering for. And it's no problem for the signal either.
I'm probably just exposing my ignorance of the boost.signals implementation. Maybe what I'm worrying about can be hidden inside the slot iterator when I get to that. I've been adapting the signals::track() stuff from mt_signal to thread_safe_signal, and as I was testing I've made an annoying discovery. I often like to set up connections in the constructor of an object which connect signals from member objects to slots which are member functions. However, it seems impossible to get a shared_ptr to "this" while inside the constructor that is useable for tracking. Are there any possible work-arounds besides using a private constructor with a static factory function (a solution which doesn't extend well to derived classes), or doing the connection setup in a member function that has to be called separately after the object is constructed? Is there some way to have signals::tracked initially hold a full shared_ptr, until it is known that the object has had a chance to have its ownership passed to an external shared_ptr? Or maybe a version of shared_from_this() which returns a shared_ptr whose use_count is initially artificially inflated by one, until an external shared_ptr comes along and tries to increment the use count. -- Frank