[boost] [thread_safe_signals] making the connection accesible from slot

Subject: [boost] [thread_safe_signals] making the connection accesible from slot
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-10-03 17:19:07

-----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-----