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

From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2007-02-19 19:58:02

On 2/19/07, Timmo Stange <ts_at_[hidden]> wrote:
> 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" ;).
>

I understand that, but I guess I'm still clinging to the idea that for
most uses, you do want to wait, and won't be in a situation where you
could deadlock.  We are just moving along the line of how hard/easy it
is to use and how hard/easy it is to deadlock.  The biggest step is
just moving the locking out of the signal and over to the user code so
that the user has the option to handle things how they want.  From
there, it is what do you want to make easy/hard, encourage/discourage.

Tony

P.S. the 'event' primitive would be pretty easy to implement.  But
yeah, it doesn't really exist currently.