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