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