From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-02 11:39:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Timmo Stange wrote:
> For a quick summary: everybody agreed on dropping the "trackable"
> base class design as it cannot be made thread-safe. Besides that,
> compatibility with the current Boost.Signals has been maintained,
> even though it stands in the way of optimal scalability and also
> complicates the implementation.
There was also the minor change to signal::combiner()/set_combiner().
I've also just dropped signals::connection::block() and unblock() from
thread_safe_signals and replaced them with a
signals::shared_connection_block class. A shared_connection_block object
causes the connection it is created from to be blocked until the
shared_connection_block is destroyed or its unblock() method is called
manually. A connection will remain blocked for as long as any active
shared_connection_block exists. In addition to exception safety, the
shared_connection_block makes blocking useable in a multi-threaded
scenario, such as two threads independently blocking the same connection
for short periods, without additional locking.
I'm currently reasonably satisfied with the state of thread_safe_signals.
My plan now is to finish an updated version of the signals documentation
that is sufficient to describe the changes that have been made, and then
put the code and documentation in a tarball so it is easier for people to
try out. Time and experience should clarify any remaining problem areas.
The design decision that I'm most doubtful about is the explicit lock() of
tracked objects in the slot class. Peter Dimov suggested an alternative
of having a slot throw a bad_weak_ptr exception when called with an
expired tracked object. This has the advantage of allowing one slot to be
bound to another with boost::bind seamlessly, without requiring explicit
setup of tracking between the slots. Unfortunately, throwing exceptions
would require changes to the combiner interface. The most minimal change
I can see would be requiring combiners to take into account the
possibility of a slot iterator dereference throwing a bad_weak_ptr
exception. This actually doesn't seem too bad. The combiner would just
need to move on to the next slot if it catches an exception.
- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFF6FMz5vihyNWuA4URAiZEAKCMItOFXrd0KyjTeyqGWcYxAzFT1gCgwbF1
OVcDU9UVAIvcVOLkOImQWks=
=J3J0
-----END PGP SIGNATURE-----