On Saturday 20 October 2012 18:43:26 Vicente J. Botet Escriba wrote:
Le 20/10/12 16:41, Andrey Semashev a écrit :
On Wednesday 17 October 2012 07:57:33 Vicente Botet wrote:
Could you show the interface the class B look like with this traits?
Ok, I started experimenting with the idea and have put together a sort of proof of concept. Please, find attached the patch that modifies boost::timed_mutex for POSIX systems and also adds the necessary bits to Boost.DateTime. The new headers are attached separately.
The approach seems interesting. I have however some questions and remarks.
Where the types detail::thread_duration and detail::thread_time are defined? I didn't find it in the attached files.
It's in time_units.hpp.
I don't like the idea that we need to change Boost.DateTime neither Boost.Chrono. I will prefer that the Boost.DateTime and Boost.Chrono specific stay in a specific Boost.Thread file. DO you think it is possible to don't change these two libraries? if yes, how?
I wanted to keep the code backward compatible with previous Boost releases. Users don't include anything special now to use DateTime or Chrono with Thread, I wanted to keep it that way. And after the change Boost.Thread should not include these headers either, which leaves the only choice of including them in the time libraries. The intergration headers can be moved to Thread but they should be included by DateTime and Chrono and in fact I see them specific to these libraries just as much as specific to Boost.Thread. If you really want it that way, I can do that.
By default the Boost.Chrono interface should be provided including the specific file. Of course it should be possible to disable its inclusion.
All timed functions will be provided, only no time library will be included by Boost.Thread. When you include a particular time library, you automatically enable it in Boost.Thread. That's the idea. You can make the support for Boost.Thread explicit by not including the glue header in the time library, but as I said, this will break backward compatibility. I'm not sure this is a good idea.
I don't see why thread_time_traits need the second parameter. Partial template specialization seems enough to me, isn't it?
You can get away with partial specialization but that will require much more thread_time_traits specializations. For instance, DateTime defined a multitude of different duration types, each deriving from date_time::time_duration, which implements most of it. By using nested _is_boost_date_time_duration type as a tag I specialize thread_time_traits once for all these types.
4. A nice outcome of the modification is that timed_mutex interface is now
unified with regard to time units, so it is now possible to do: mtx.try_lock_for(boost::posix_time::seconds(2));
which was previously only possible with Chrono units.
This could be seen as an advantage but also as an drawback as we are multiplying the interfaces. I don't want the timed_lock to be possible with Boost.Chrono. How could this be achieved?
Why? I actually like timed_lock because it is unified for both relative and absolute timeouts. You can try to detect Chrono somehow in these functions but I don't see the point.