Re: [signals/threadsafe version] Atomic disconnects

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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost