----- Original Message ----- From: "Fabio Fracassi" To: Cc: Sent: Monday, November 10, 2008 11:30 AM Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

I have a tendency to yes, because even now it is better than what we have now (which is not saying that signals1 was bad!), on the other hand I think that the missing documentation is crucial.

I think that a mini review would ensure that the documentation is updated as we expect. Vicente

Hi, I don't have a review... I have made a few tests with the library. I think the library is good, but I don't know if I make something wrong, but it seems for me that the library is slow. I have made a few tests with VC++ 8.0 and _SCL_SECURE=0 and it seems that it is about 50 times slower than a normal boost::function with a bind.... It's a lot... Best regards Hansjörg The test code was: class PerformanceCounter { private: LARGE_INTEGER CurrentTickCount_; LARGE_INTEGER OldTickCount_; LARGE_INTEGER TickFrquency_; double EllapsedTime_; double TotalTime_; public: PerformanceCounter(): EllapsedTime_(0.0), TotalTime_(0.0) { ::QueryPerformanceFrequency(&TickFrquency_); ::QueryPerformanceCounter(&CurrentTickCount_); OldTickCount_ = CurrentTickCount_; } void Reset(const double intial_time = 0.0) { TotalTime_ = intial_time; EllapsedTime_ = intial_time; ::QueryPerformanceCounter(&CurrentTickCount_); OldTickCount_ = CurrentTickCount_; } void CalculateEllapsedTime() { ::QueryPerformanceCounter(&CurrentTickCount_); EllapsedTime_ = (double)(CurrentTickCount_.QuadPart - OldTickCount_.QuadPart)/TickFrquency_.QuadPart; TotalTime_ += EllapsedTime_; OldTickCount_ = CurrentTickCount_; } void CalculateEllapsedTime(const PerformanceCounter& to_intialize) { CurrentTickCount_ = to_intialize.CurrentTickCount(); EllapsedTime_ = (double)(CurrentTickCount_.QuadPart - OldTickCount_.QuadPart)/TickFrquency_.QuadPart; TotalTime_ += EllapsedTime_; OldTickCount_ = CurrentTickCount_; } const LARGE_INTEGER& CurrentTickCount() const {return CurrentTickCount_;} double EllapsedMilliseconds() const {return EllapsedTime_ * 1000;} double EllapsedSeconds() const {return EllapsedTime_;} double TotalTime() const {return TotalTime_;} }; template <typename ParamT> class EventHandlerBase1 { public: virtual void notify(ParamT param) = 0; }; template class EventHandler1 : public EventHandlerBase1<ParamT> { typedef void ( ListenerT::*PtrMember)(ParamT); ListenerT* m_object; PtrMember m_member; public: EventHandler1(ListenerT* object, PtrMember member) : m_object(object), m_member(member) {} void notify(ParamT param) { (m_object->*m_member)(param); } }; template <typename ParamT> class EventHandlerFunc1 : public EventHandlerBase1<ParamT> { typedef void ( * HandlerFunc)(ParamT); HandlerFunc m_handler; public: EventHandlerFunc1(HandlerFunc f) : m_handler(f) {} void notify(ParamT p) { m_handler(p); } }; template <typename ParamT> class EventHandlerStdCallFunc1 : public EventHandlerBase1<ParamT> { typedef void (_stdcall * HandlerFunc)(ParamT); HandlerFunc m_handler; public: EventHandlerStdCallFunc1(HandlerFunc f) : m_handler(f) {} void notify(ParamT p) { m_handler(p); } }; /// <summary> /// C++ event with one parameter /// </summary> template <typename ParamT> class CppEvent1 { typedef std::map< int, EventHandlerBase1<ParamT> *> HandlersMap; HandlersMap m_handlers; int m_count; public: CppEvent1() : m_count(0) {} ~CppEvent1() { HandlersMap::iterator it = m_handlers.begin(); for(; it != m_handlers.end(); it++) { delete it->second; } } /// <summary> /// Attach a member function to the event /// </summary> template <typename ListenerT> CppEventHandler attach(ListenerT* object,void (ListenerT::*member)(ParamT)) { typedef void (ListenerT::*PtrMember)(ParamT); m_handlers[m_count]=new EventHandler1(object,member); m_count++; return m_count-1; } typedef void ( * Callback)(ParamT); /// <summary> /// Attach a static function to the event /// </summary> CppEventHandler attach(Callback f) { m_handlers[m_count]=new EventHandlerFunc1<ParamT>(f); m_count++; return m_count-1; } typedef void (_stdcall * MngCallback)(ParamT); /// <summary> /// Attach a managed function to the event /// </summary> CppEventHandler attach(MngCallback f) { m_handlers[m_count]=new EventHandlerStdCallFunc1<ParamT>(f); m_count++; return m_count-1; } /// <summary> /// Detach an event handler from the event /// </summary> bool detach(CppEventHandler id) { HandlersMap::iterator it = m_handlers.find(id); if(it == m_handlers.end()) return false; delete it->second; m_handlers.erase(it); return true; } /// <summary> /// Fire the event /// </summary> void notify(ParamT param) { HandlersMap::iterator it = m_handlers.begin(); for(; it != m_handlers.end(); it++) { it->second->notify(param); } return; } }; CppEvent1< char > cppEvent; class TestCppEvent { public: CppEventHandler eventHandler; int counter; void Open() { eventHandler = cppEvent.attach(this,&TestCppEvent::OnEventReceived); counter=0; } void Close() { cppEvent.detach(eventHandler); } void OnEventReceived(char b) { counter++; } }; class TestBind { public: int counter; TestBind():counter(0){} void OnEventReceived(char b) { counter++; } }; class TestSignal { public: int counter; TestSignal():counter(0){} void OnEventReceived(char b) { counter++; } }; int _tmain(int argc, _TCHAR* argv[]) { PerformanceCounter timer; TestCppEvent testCppEvent; testCppEvent.Open(); timer.Reset(); for(int i = 0; i < 10000000; i++) { cppEvent.notify('a'); } timer.CalculateEllapsedTime(); testCppEvent.Close(); cout<<"Zeit[TestCppEvent]:"< f = boost::bind(&TestBind::OnEventReceived,&testBind,_1); timer.Reset(); for(int i = 0; i < 10000000; i++) { f('a'); } timer.CalculateEllapsedTime(); cout<<"Zeit[TestBind]:"< sig; sig.connect(boost::bind(&TestSignal::OnEventReceived,&testSignal,_1));; timer.Reset(); for(int i = 0; i < 10000000; i++) { sig('a'); } timer.CalculateEllapsedTime(); cout<<"Zeit[TestSignal]:"<

Here is a late review.

...

* What is your evaluation of the design?

Excellent. The design of Boost.signals is excellent, and Boost.signals2 follows the same design.

Boost.signals2 should provide an optional (non-thread safe) compatibility mode with Boost.signals. This mode should not be available by default, but only if the user defines some macro. This will make porting from Boost.signals to Boost.signals2 much smoother.

Frank also mentioned the possibility of adding a thread safe version of boost::trackable based on boost::enable_shared_from_this. That would be a very valuable addition to the library.

...

* What is your evaluation of the implementation?

Have not looked at the implementation.

...

* What is your evaluation of the documentation?

I agree with the other reviewers that it could be improved.

...

* What is your evaluation of the potential usefulness of the library?

Very useful. The lack of thread safety is the main weakness of Boost.signals, and is the only point where Boost.signals is inferior to the Qt signals.

...

* Did you try to use the library? With what compiler? Did you have any problems?

Tried with MSVS 9.0. No problems.

...

* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?

Read the docs. Wrote, compiled and ran a few simple examples.

...

* Are you knowledgeable about the problem domain?

Yes. I do all my work in an event-driven framework. The three Boost libraries I use most are smart pointers, bind and signals. I also have a lot of experience with the Qt signals.

...

* Do you think the library should be accepted as a Boost library?

Yes. We need thread safe signals.

Many thanks to Frank for submitting this excellent library, Johan Råde

Johan Råde wrote:

Frank also mentioned the possibility of adding a thread safe version of boost::trackable based on boost::enable_shared_from_this. That would be a very valuable addition to the library.

Second that! While I love the generality of the explicit tracking, I've been jumping through some hoops trying to adapt existing Boost.Signals code that uses boost::trackable. If signals2 could provide a thread-safe version of boost::trackable, it would make conversion a much easier "sell" within my organization.

Sorry for the long delay... I got behind on the Boost list and am only gradually catching up. :-(

...

Johan Råde wrote:

...

...

Frank also mentioned the possibility of adding a thread safe version of boost::trackable based on boost::enable_shared_from_this.

Frank Mori Hess wrote:

I have added a thread-UNsafe boost::signals2::trackable to svn to ease porting of single-threaded Boost.Signals code that doesn't need to be made thread-safe.

That will be useful transitionally if we can count on a thread-safe boost::signals2::trackable arriving later. If signals2::trackable would only ever be thread-unsafe, it's not useful to us. I recently introduced into our code some machinery based on boost::signal. Others are concurrently working on multithreading. I don't want my new functionality to become a source of difficult race bugs -- or even to be /perceived/ that way. I want to avoid a label of: "this mechanism is thread-unsafe, avoid it in all new code." Accordingly, I've just replaced boost::signal with boost::signals2::signal, and so forth, throughout our code. There were several existing uses of boost::trackable. I've coded around them in several ways, as described below. Since I didn't introduce them, I don't know the author's intent.

Would you give a little more detail on what parts of boost::trackable porting you've found the most painful?

Those of you uninterested in details can skip the rest. :-) My Holler class contains a boost::signals2::signal. For simple usage ignoring lifespan issues (e.g. connecting a free function), I have a Holler::listen(const slot_type&) method. It's nice that with boost::trackable, the same listen() method Just Works. With an instance 'smartptr' of ListenerClass derived from boost::trackable, I'd like to write something like: holler.listen(boost::bind(&ListenerClass::method, smartptr, _1)); If my listen() method were able to tease apart the object returned from bind(), it could detect the case of a shared_ptr. Since I don't know how to do that, I've introduced a number of alternative ways to get disconnect-on-destruction. I don't yet know which, if any of them, will become the prevalent idiom. None is as easy/foolproof as boost::trackable, since each requires the caller to explicitly request connection management. Maybe I'm overlooking something that would make my life much easier -- suggestions welcome! 1. I've introduced a template Holler::listen() overload like this: template connection listen(void (CLASS::*method)(const Data&), const boost::shared_ptr<POINTEE>& pointer); Thus, instead of writing: holler.listen(boost::bind(&SomeClass::method, ptr, _1)); you'd write: holler.listen(&SomeClass::method, ptr); This method instantiates a slot_type object, passes 'pointer' to its track() method and then calls the other listen() overload: slot_type listener(boost::bind(method, pointer.get(), _1)); // n.b. gcc 3.3 doesn't like listener(method, pointer.get(), _1) listener.track(pointer); return listen(listener); 2. For transient objects not managed by shared_ptr, I've also introduced a Trackable base class containing boost::ptr_vectorboost::signals2::scoped_connection mConnections; The Trackable::track(const connection& c) method does this: mConnections.push_back(new scoped_connection(c)); So destroying a Trackable subclass object disconnects any connections passed to track(). Again, if my Holler::listen() method could detect a bind() involving a TrackableSubclass*, it could implicitly call Trackable::track(). 2a. You can explicitly engage track() using syntax such as: listenobj.track(holler.listen(boost::bind(&TrackableSubclass::method, listenobj, _1))); Trackable also defines a suite of listenTo() methods: 2b. connection listenTo(Holler&, const slot_type&); 2c. // harmonious with the Holler::listen() overload template connection listenTo(Holler&, void (CLASS::*method)(const Data&), const POINTER& pointer); // doesn't need to be boost::shared_ptr because we're // using Trackable::track() rather than slot_type::track() 2d. // for a Trackable subclass object to bind one of its own methods template <class CLASS> connection listenTo(Holler&, void (CLASS::*method)(const Data&)); 3. One of my colleagues has a class that (with my changes) now also wraps a boost::signals2::signal. He strongly dislikes the variation between my listen(const slot_type&) and listen(method ptr, shared_ptr) methods, so he's changed his own connectFor() method as follows: template <typename POINTER> connection connectFor(const slot_type& slot, const POINTER& ptr) { connection c(mSignal.connect(slot)); Trackable* isTrackable(dynamic_cast(ptr)); if (isTrackable) { isTrackable->track(c); } return c; } (Yes, this could be made cleverer to notice when POINTER is actually a boost::shared_ptr<SOMETHING>. Next iteration.) So you subscribe to his class with a uniform call such as: obj.connectFor(boost::bind(&SomeClass::method, aPointer, _1), aPointer); But then you have to pass a NULL pointer for the case of a free function -- leaving open the possibility that someone will carelessly copy-and-paste the wrong example instance and pass NULL with a boost::bind() expression. As I said above, every one of these approaches requires coding something other than the intuitive listen(boost::bind(etc.)) call, meaning you must know when you need to request connection management. The variety of options is undoubtedly a bad thing: how to choose? You must know way more than you should about what I had in mind. A thread-safe boost::signals2::trackable mechanism would allow us to drop back to a single universal call: holler.listen(boost::bind(&SomeClass::method, ptr, _1)); with connection management automatically engaged as appropriate. A transitional thread-unsafe boost::signals2::trackable would be tenable for now... but if boost::signals2::trackable were only ever going to be thread-unsafe, I couldn't encourage people to use it: we'd be responsible for propagating new thread-unsafety through an application to which we're even now adding threads.

Frank Mori Hess wrote:

...

If my listen() method were able to tease apart the object returned from bind(), it could detect the case of a shared_ptr.

It could, by using boost::visit_each. boost::bind supports visit_each to let you apply a visitor to all the objects bound inside the returned functor. The signals libraries use visit_each to discover trackable objects that have been bound into slots.

I would spend some time learning how to use visit_each with bind. You could implement a wrapper function that inspects slots for your own Trackable base class objects, and then takes whatever step is needed to extract a shared_ptr and pass it to slot::track before connecting.

Thanks for the suggestion! I'm excited about this approach, but I've run into a snag. As you note above, in addition to the case of my own Trackable base class, I want my visitor to detect a bound boost::shared_ptr<anything> and pass the shared_ptr to my new slot_type object's track() method. In fact, for a boost::shared_ptr<SomeTrackableSubclass>, I want the shared_ptr tracking to take precedence. As you said, this is the safer mechanism. I can in fact detect a bound shared_ptr and pass it to track() as I want. The problem is that binding a shared_ptr captures a copy, so the referenced object will live until the connection is explicitly disconnected! That makes the slot_type::track() mechanism moot. It looks as though I could only achieve what I want if my visit_each() visitor could *modify* the boost::bind object to replace the bound shared_ptr with its wrapped plain pointer. I don't believe this is possible? (Aside: I tried extending my visitor's detection to boost::weak_ptr, changing my test code by explicitly converting my shared_ptr to weak_ptr before passing it to boost::bind(). I couldn't instantiate slot_type(boost::bind(...boost::weak_ptr<anything>...)) until I specialized boost::get_pointer() myself. (I'm using Boost 1.34.1 augmented with the Signals2 library.) In any case, though, requiring coders to remember to explicitly wrap any boost::smart_ptr instance in boost::weak_ptr feels like the wrong solution.) Perhaps I could build a sufficiently smart boost::visit_each() visitor to reconstruct the original boost::bind() expression, but substituting a plain pointer for any smart_ptr? I'm not confident I can do that without relying on too many boost::bind implementation details. I'm hoping one of you will suggest a better approach. :-)

Just a note: you need to be careful about connecting these transient objects, since the signal can't employ shared_ptr to prevent them from destructing in mid-signal invocation.

Thanks for the warning. I'd prefer to handle bound shared_ptrs, if I can do so without making the referenced objects immortal.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 February 2009, Nat Goodspeed wrote:

Nat Goodspeed wrote:

...

I want my visitor to detect a bound boost::shared_ptr<anything> and pass the shared_ptr to my new slot_type object's track() method.

Frank, that functionality isn't specific to either boost::trackable or my own Trackable base class. Supposing we can resolve the problem of a bound copy of a shared_ptr (previous message in thread), couldn't the Signals2 library incorporate that logic itself?

I don't view the "dynamically replace bound shared_ptr with weak_ptr in incoming bind functor" idea as viable. But if you mean the general feature of searching for some base class during connect and automatically tracking those objects, that might get added in the future. I would do it strictly as an optional extension though, in seperate headers and only using the library's existing public interfaces. It would add a free function findable by ADL that would look for the trackable base class when connecting, something like: class shared_trackable: public enable_shared_from_this {}; namespace bs2 = boost::signals2; template bs2::connection connect(Signal &sig, const Func &f) { typename Signal::slot_type myslot(f); // apply visitor to f here which finds shared_trackable objects // and tracks their owning shared_ptr... shared_trackable_visitor visitor(myslot); visit_each(visitor, f); return sig.connect(myslot); } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmcHFQACgkQ5vihyNWuA4XvTACgl0tpUa0XYnvWjJaDCS1HBPn+ tJMAoITCZWlj/046/bklVcnTDgN8q0gi =usvO -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 18 February 2009, Nat Goodspeed wrote:

Frank Mori Hess wrote:

...

But if you mean the general feature of searching for some base class during connect and automatically tracking those objects, that might get added in the future. I would do it strictly as an optional extension though, in separate headers and only using the library's existing public interfaces. It would add a free function findable by ADL that would look for the trackable base class when connecting, something like:

class shared_trackable: public enable_shared_from_this {};

If I understand correctly, we expect the coder to pass to boost::bind() a plain pointer, a reference or a weak_ptr to a shared_trackable subclass instance. None of those will artificially prolong the life of that instance. However, using enable_shared_from_this lets your visitor obtain a shared_ptr to pass to slot_type::track(). Yes?

Yes

It's still the case that if the coder passes to boost::bind() an actual shared_ptr to the shared_trackable subclass instance, the slot_type::track() mechanism becomes irrelevant because the object won't die. That might warrant a note in the documentation for this feature.

Yes, that's why I suggested you could have the visitor give a compile error on finding a shared_ptr in the bind functor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmdcTUACgkQ5vihyNWuA4WD6wCgn9OC6qi4QLLfGPa2xSArHzTf NmsAniN+eywOOJvKvyumqj7b3z1Wj2VJ =G27o -----END PGP SIGNATURE-----

On Thursday 19 February 2009, Nat Goodspeed wrote:

Then there's the interesting question as to whether my visitor should complain about *any* shared_ptr in the boost::bind() object, since any such object becomes effectively immortal.

If my visitor handles weak_ptr<anything> by passing the corresponding shared_ptr<anything> to slot_type::track(), then it seems reasonable to me to force our coders to convert any shared_ptr to weak_ptr before boost::bind()ing it. Does that make sense?

In that case I don't really understand why my visitor would need to distinguish between shared_ptr and shared_ptr -- or weak_ptr and weak_ptr.

Put differently, shared_trackable only seems to me to make a difference when the visitor encounters a plain pointer or reference to it. In that case, the visitor can use shared_trackable::shared_from_this() and still pass a shared_ptr to slot_type::track(). Am I overlooking something?

There is nothing inherently wrong with binding a shared_ptr to a slot. I've done it intentionally myself before. It doesn't necessarily make anything immortal. It's only a problem when the shared_ptr bound to the slot owns an object "A", and then slot is connected to a signal which also lives somewhere inside "A". Then you have the usual shared_ptr-cycle problem, which can be broken by using a weak_ptr and slot::track. But you may be binding a shared_ptr which owns an object "B" which is totally unrelated to object containing the signal you are connecting to. Or, even if objects "A" and "B" are the same type, the objects might for example be arranged in some kind of tree where a shared_ptr owning child object "A" is bound to a slot connected to a signal inside a parent object "B".

Frank Mori Hess wrote:

On Tuesday 17 February 2009, Nat Goodspeed wrote:

...

I can in fact detect a bound shared_ptr and pass it to track() as I want. The problem is that binding a shared_ptr captures a copy, so the referenced object will live until the connection is explicitly disconnected! That makes the slot_type::track() mechanism moot.

It looks as though I could only achieve what I want if my visit_each() visitor could *modify* the boost::bind object to replace the bound shared_ptr with its wrapped plain pointer. I don't believe this is possible?

Wouldn't it be better just to make your visitor just detect a bound shared_ptr to Trackable and report it, forcing the calling code to get it right? You could use BOOST_STATIC_ASSERT to give a compile-time error, for example.

I'm sorry, I didn't express myself clearly. There are actually several different cases: 1. visitor discovers plain pointer/reference to a subclass of my Trackable base class: Use Trackable to track the new connection. This is working now -- but as you point out, it's less safe than your slot_type::track() mechanism since a Trackable might be destroyed during a slot call. 2. visitor discovers a shared_ptr to something other than a Trackable subclass: This is the case I was asking about. My visitor can in fact pass the shared_ptr to slot_type::track(), but it's pointless because the shared_ptr copy stored in the boost::bind() result makes the referenced object effectively immortal. To my surprise, I find that it's not destroyed even when I explicitly disconnect the resulting connection. 3. visitor discovers a weak_ptr to something other than a Trackable subclass: Though I had to specialize boost::get_pointer() for weak_ptr myself, with that in place, this case works now. My problem is that I can't imagine every coder consistently remembering to convert a shared_ptr to weak_ptr before passing it to boost::bind(). 4. visitor discovers a shared_ptr to a Trackable subclass: This is the case you mention above. To tell you the truth, though, this doesn't look like an error to me. In effect, I have a choice between two different connection-management mechanisms. Given that slot_type::track() is safer than my Trackable mechanism, I'd prefer to use that -- but unless we can somehow create a new boost::bind object that omits the bound shared_ptr, it's moot. 5. visitor discovers a weak_ptr to a Trackable subclass: I currently use the slot_type::track() mechanism for this case too. In other words, once the visitor discovers a shared_ptr or weak_ptr, it stops caring about the pointee type.

Frank Mori Hess wrote:

On Wednesday 18 February 2009, Nat Goodspeed wrote:

...

1. visitor discovers plain pointer/reference to a subclass of my Trackable base class:

Use Trackable to track the new connection.

This is working now -- but as you point out, it's less safe than your slot_type::track() mechanism since a Trackable might be destroyed during a slot call.

There's also the fact that disconnect doesn't get called until the base class destructor (after the derived class destructors have already run). Really, you might as well be using boost::signals2::trackable for this case, since it is equivalent to what you are doing

Now that it's been introduced [1], I will, thanks!

(although I'd avoid this case entirely if you care about thread-safety).

I understand and agree. Thanks for explaining the details of the vulnerabilities. This now becomes an awareness problem on our side. We have existing uses of the original Boost.Signals library, and some existing classes derived from the original boost::trackable. I don't yet understand the authors' intent, or the typical lifespans of these classes. Nonetheless I'm trying to switch all such usage over to Signals2 with a minimum of disruption so that, as more threads are introduced, we at least have a way to improve thread-safety. I introduced a Trackable base class only as a drop-in, Signals2-compatible replacement for boost::trackable. Since you've now done that officially, mine becomes entirely moot. At the moment I don't want to have to change over the affected classes to be managed by shared_ptr. If I understand correctly, that's the best way to defend a given class against this particular family of race conditions. We're going to have to tackle those incrementally.

...

2. visitor discovers a shared_ptr to something other than a Trackable subclass:

the shared_ptr copy stored in the boost::bind() result makes the referenced object effectively immortal.

To my surprise, I find that it's not destroyed even when I explicitly disconnect the resulting connection.

It will get destroyed eventually. The signal cleans up its slot list little by little during connect/invoke. It doesn't immediately remove disconnected slots from the slot list since other threads might be using the same slot list concurrently.

Ah -- thanks for clarifying! I wrote a unit test that monitors the lifespan of the class containing my slot method. (The test class binds a bool&, setting it on construction and clearing it on destruction.) I called connection::disconnect(), then immediately inspected that bool flag. Hence my remark above.

It might be possible to make it immediately reset the shared_ptr owning the slot though, leaving an empty shared_ptr in the slot list, since that wouldn't invalidate any iterators.

I like that idea, on the Principle of Least Astonishment. :-) And by the way -- since I don't seem to have expressed this earlier -- many thanks for your work on Signals2! I really appreciate having a migration path to better thread safety. I fear that some of my earlier messages could be read as complaints, when in reality I'm very enthused about switching over. Now if I only had a way to transform a boost::bind() object, replacing any embedded shared_ptr<Foo> with weak_ptr<Foo>, life would be perfect. ;-) But for now, your suggestion of a compile error should work fine. [1] http://www.boostpro.com/vault/index.php?action=downloadfile&filename=signals2-2009-02-11.zip&directory=thread_safe_signals&