From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-19 19:33:15
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