Re: [boost] [thread_safe_signals][signals2] call forreviewers(review tentatively scheduled Nov 1st - Nov 10th)

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-----
Hash: SHA1

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

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 
Boost.Signals does.

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

> 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

http://www.nabble.com/-lightweight_mutex--Patch-to-support-new-thread-api-td19717350.html

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)

iD8DBQFI97Hd5vihyNWuA4URAk+JAJ4mvrNSAT/7Ut7l6b+wm2UH8knnzgCeKjYC
reXT+mc9BFqtZAe08geVKj0=
=lXMy
-----END PGP SIGNATURE-----