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

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