Re: [boost] [thread] Integration with Chrono and DateTime

Subject: Re: [boost] [thread] Integration with Chrono and DateTime
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-10-20 13:50:22

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.