Re: [Boost-users] [signals] Automatic connection management and MT

From: Timmo Stange (ts_at_[hidden])
Date: 2007-02-04 15:36:50

Timmo Stange wrote:

> I took Boost.Signals, removed grouping, naming and tracking
> (which are together responsible for more than half of the code)
> and added rudimentary threading support with a single
> recursive_mutex. I didn't want to spam the list with several
> kB of compressed code, so I put it here:
>    http://www.sepulchrum.com/sources/mt_signals.tar.gz

I've cleaned it up a bit, added some comments and replaced
the internal IF template with mpl::if_ (as that was a docu-
mented todo).

There are a few things I am unsure about in the original
implementation:
- Why does the signal use the pimpl idiom? I don't see any
immediate advantage in it.
- Is it safe to assume that only temporary slot_call_iterators
will ever be dereferenced with the single_pass_traversal_tag? That's
how I understand the docs, but it's crucial to my implementation
and I better ask twice ("*i++;", no "*i, ++i;").
- Is it really desirable to completely replace the current implemen-
tation with a thread-safe one (parameterizable or not) while it
seems clear that the tracking mechanism will definitely be different
for each version?

I've tested my version with random_signal_system.cpp and was sur-
prised it did not crash despite the lack of trackable. The bacon
test naturally fails occasionally, as connections that should have
been removed by the tracking functionality are miraculously re-
vived to point to newly added signals. We will obviously need a
full wrapper for the weak_ptr to trackable objects, for the
inspection through visit_each to work as expected. I suggest a
signals::tracked<function_type> class that wraps the actual
weak_ptr and a smart_ptr that may be used to lock() the weak_ptr
and reset it through two simple member functions lock() and
unlock(). A convenience function for boost::bind with the name
signals::track() can be used to instantiate such an object
similar to std::make_pair(). The simplest way to interface with
those signals::tracked<...> objects would be an abstract base
class with virtual lock() and unlock(), if we accept the possible
code bloat that may involve (locking a series of weak_ptrs into
smart_ptrs for every signal invocation won't win any performance
awards anyway).

Regards

FarCry