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