Gottlob Frege wrote:
This is starting to sound promising. I could also imagine that disconnect returns some kind of event that you can choose to wait on or not.
[...]
ie, the signal code, instead of calling the disconnect callback, triggers the event.
Not as generic as a callback, but maybe more efficient?
Leaving aside the lack of a simple event primitive in Boost.Threads, we could easily provide a predefined callback functor in Signals that implements this, but I have the feeling we're running in circles here, because that is exactly what we don't want the client code to do: If two slots use that approach with disconnect, the outcome may be a deadlock - not on the slot mutexes this time, but on the "slot return events" ;). Regards Timmo Stange