Subject: Re: [boost] [thread_safe_signals][signals2] call forreviewers(review tentatively scheduled Nov 1st - Nov 10th)
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-10-16 17:27:53
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 15 October 2008 13:58 pm, vicente.botet wrote:
> > Now, if it is decided in review that something like a
> > boost::signals2::trackable needs to be added to ease the pain of porting,
> > that is something that would deserve more exposition in the API changes
> > section of the docs. And discussion/example usage of a
> > signals2::trackable class wouldn't belong in the tutorial, since I'd want
> > to discourage new users from using it.
> Do you mean that signals2::trackable could be included without
I'm not certain this is what you're asking, but yes it would be possible to
implement a signals2::trackable on top of the signals2 automatic connection
management scheme (in fact I did have it implemented at one point). It
wouldn't be thread-safe, but it could do everything the boost::trackable from
> You have misunderstood my concern. I'm talking about a benchmasrk on a
> single threaded application without any mutex. Nothing to be with the
> Thread library.
Oh. Yes, some benchmarking would be good to post to this list at the
beginning of the review. I'll try to do that if we get enough reviewers to
run with. Probably it would be good add a benchmark with a signal invoking
slots with connection tracking enabled (a scenario I imagine Boost.Signals
would win over Signals2). Of course, anyone could benchmark and post the
> Are you sure that boost::mutex is not header only?
Yes, unless it has been fixed recently. Both it and the lock classes pull in
exception classes that are defined only in the compiled thread library.
> Maybe you are right, but when an application needs thread safe signals
> usually it will work with mutex, directly or indirectly.
> Can a user give a boost::mutex as parameter of the signal class?
Yes, any mutex that models the simple Lockable concept from Boost.Thread can
be used. Hmm, I meant to document that fact in the signals2::signal
reference but it looks like I forgot. I only mention the Lockable concept
and boost::mutex in the reference of signals2::mutex.
> I don't think that we need to reinvent the weel because the header files
> are not lightweight. Why not contribute to the Thread library making a
> proposal for a lightweight_mutex?
I got the impression from Anthony that boost::mutex was intended to be
header-only, and he intends to fix the problem. I also posted a patch to
detail::lightweight_mutex which makes it support the Lockable concept
I'll gladly drop my implementation of signals2::mutex (which is a patched
version of detail::lightweight mutex) when either boost::mutex or
detail::lightweight_mutex becomes a suitable replacement.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk