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

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-19 17:12:27

Frank Mori Hess wrote:

>> Alternatively, disconnect() could return a bool 
>> if the disconnected slot is currently running or throw an exception.
>> That could be optional through an argument (disconnect(true)) or
>> a different function (checked_disconnect()). A connection::wait()
>> function could wait for all pending calls to finish, but couldn't
>> be safely called from a signal invocation context.
> 
> I like connection::wait() better.  a return value from disconnect still 
> wouldn't be able to tell you when the slot is really gone, only that it 
> wasn't gone when disconnect returned.

How about an optional callback parameter for disconnect(), which usually
will be called immediately after the successful disconnection or, in the
rare case of the slot being run on another thread at the time of the
disconnection, after it returned (naturally from the other thread's
context then)? Not specifying this parameter would imply that the caller
has taken the necessary precautions to avoid all possible problems
(either by externally synchronizing signal calls or by not relying on
strong disconnect semantics).

The reason for this idea is simplicity of use. Keeping a close watch
on resources you share between threads is everyday work, so in many
cases special handling for the concurrent disconnection/invocation
will not be necessary. In all other cases (when the user has no
access to the called code, for example), the tools we provide should
be tailored to the problem: this concurrency situation is rather
unlikely and the common case should result in synchronous behavior.
My connect::wait() idea would often force the user to run a separate
maintenance thread for resource cleanup, in which he performs those
waits - a high cost (design- and performace-wise) for something that
is unlikely to happen.

Regards

Timmo Stange