Re: [boost] [signals/threadsafe version] Atomic disconnects

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-03-09 11:13:18

On Sunday 09 March 2008 05:21, Johan Torp wrote:
> Thanks for the clarification. This solution forces the use of
> shared_ptrs and might keep a Foo instance alive a little bit longer.
> Especially the latter requirement is a no-no for me.

I could add something like a "join()" method to the connection class, which 
would block until the associated slot is finished running.  Then you could 
just follow your disconnect() call with a join(), if you are sure it won't 
result in deadlock.

> The callbackrequester implementation -typically a queue - switches to
> the thread which the synchronous slot "belongs" to. This is of course
> very intrusive to the entire design of an application -

Yes, I don't think this belongs in a signals library.  If you have a 
separate event loop/method request framework, you can just implement a 
slot which simply queues an event in the desired thread's event queue.  
Or, it would also be very similar to just having your slot send a method 
request to an active object (resisting urge to plug my active object lib 
once again...).

> callbackrequesters implementations need to exist for all threads and be
> passed around all over the application. However, it made it possible to
> implement a safe scoped_connection with RAII semantics. User code look

-- 
Frank