-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious if anyone has a good idea on how to make a slot's connection easily accesible to it when it is running. A common case is a slot blocks it's own connection to avoid infinite recursion when it is about to do something that will cause its signal to be invoked again. The problem is, for a slot to block its own connection, it needs access to a connection object. But it is a pain in a multi-threaded situation to pass the connection to the slot, since the connection is not available until after the slot has already been connected to the signal. In a single-threaded program, you can do something like: namespace bs2 = boost::signals2 bs2::signal<void (void)> sig; void myslot(boost::shared_ptr<bs2::connection> conn); boost::shared_ptr<bs2::connection> conn(new bs2::connection); *conn = sig.connect(boost::bind(&myslot, conn)); void myslot(boost::shared_ptr<bs2::connection> conn) { //... { bs2::shared_connection_block blocker(*conn); //... } } However, even in thread_safe_signals, assignment of a connection object is not thread-safe. So if the signal can be invoked concurrently, you would need to protect the connect with a mutex, and also protect any use of the connection inside the slot with the mutex, which starts to get a bit tedious. Maybe an additional connect overload for signals, which takes a slot that has an additional parameter added to its signature (a reference to its connection)? For example, for a signal<void (int)> The slot_type is usually slot<void (int), function<void (int)> > I could add an extended_slot_type typedef as a slot<void (int, const connection&), function<void (int, const connection&)> > Then I would add overloads to signalN::connect which accept the new extended_slot_type. That would also mean an additional template parameter for signals, like ExtendedSlotFunction. Or, the SlotFunction template could be dropped entirely and the signal class hard-coded to use boost::function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI5oxM5vihyNWuA4URAhKkAJwImDkQjMXbBD+81a925QXS5vKvNACgkBr9 dGC3G/2YLGVRu/CJl1zUzSY= =3oKu -----END PGP SIGNATURE-----