2014/1/16 Bjorn Reese <breese@mail1.stofanet.dk>

On 01/16/2014 06:51 AM, Oliver Kowalke wrote:

...

are the time_point-types of the clock-types from boost.chrono convertible into each other?

chrono::system_clock::time_point t = convert_fun( chrono::steady_clock::now() ) etc. ?

chrono::steady_clock::time_point t1 = chrono::steady_clock::now(); chrono::steady_clock::duration d1 = t1.time_since_epoch(); chrono::system_clock::duration d2 = chrono::duration_cast<chrono:: system_clock::duration>(d1); chrono::system_clock::time_point t2(d2);

Are you saying the epoch is the same for steady_clock and system_clock? "There is no fixed relationship between values returned by steady_clock::now() and wall-clock time." [1] Regards, Kris [1] http://www.boost.org/doc/libs/1_55_0/doc/html/chrono/reference.html#chrono.r...

On Thu, Jan 16, 2014 at 3:53 AM, Krzysztof Czainski <1czajnik@gmail.com> wrote:

2014/1/16 Bjorn Reese <breese@mail1.stofanet.dk>

...

On 01/16/2014 06:51 AM, Oliver Kowalke wrote:

...

are the time_point-types of the clock-types from boost.chrono convertible into each other?

chrono::system_clock::time_point t = convert_fun( chrono::steady_clock::now() ) etc. ?

chrono::steady_clock::time_point t1 = chrono::steady_clock::now(); chrono::steady_clock::duration d1 = t1.time_since_epoch(); chrono::system_clock::duration d2 = chrono::duration_cast<chrono::system_clock::duration>(d1); chrono::system_clock::time_point t2(d2);

Are you saying the epoch is the same for steady_clock and system_clock? "There is no fixed relationship between values returned by steady_clock::now() and wall-clock time." [1]

I'm not sure why you would want to. If clock-credibility is in question, the best you can do is synchronize your system clock. Other than that, steady_clock is what you want for high-precision timing. Casual inspection of the Boost.Chrono code will tell you that. If it's still a problem, you might have a problem with your platform, hardware, etc.

Regards, Kris

[1] http://www.boost.org/doc/libs/1_55_0/doc/html/chrono/reference.html#chrono.r...

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2014/1/16 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>

Olivers, such a conversion is not possible with the current interface.

that's pity - because I've the problem to achieve your request regarding to make the algorithm interface accepting every time_point provided by or derived from boost.chrono. the interface 'algorithm' has pure virtual functions only, so I can't use templated functions (e.g. make clock-type an template argument). another solution would be making the interface class itself to an template (using the clock-type as template arg.). but this breaks the API because every class (even fiber itself) of the lib depended on the template arg of algorithm. this is caused by the fact that the scheduler implementation (derived from interface 'algorithm') is accessed through a pointer of type 'algorithm'. for instance mutex::lock() suspends a fiber if the mutex is already locked by another fiber. suspending is done by calling algorithm::wait(). this is done via detail::scheduler::instance()->wait(); as you see - scheduler::instance() returns the pointer to algorithm (stored inside a static thread_specific_ptr). thus scheduler must know the template argument of algorithm and therefore mutex needs too. As you see all class would be affected and this makes the API itself unusable. do you have any other idea to get your request from the review working? or might it acceptable to use on clock-type from boost.chrono?

2014/1/17 Bjorn Reese <breese@mail1.stofanet.dk>

Do you have to use time_point, or will duration suffice?

because the interface should be equivalent to std::thread API both, time_point and duration, are required

On Fri, Jan 17, 2014 at 9:39 AM, Agustín K-ballo Bergé <kaballo86@hotmail.com> wrote:

Your API exposes both time_point and duration, that doesn't mean you have to use them internally. What (I think) Bjorn is pointing at is that durations are clock agnostic, so you should build your internal implementation using the most precise duration you are willing to support instead of using a clock. You can then turn any time_point or duration into the specific duration you deal with internally, right at the outermost layer.

Vicente (author of Boost.Chrono) has already explained this on the thread where he requests this functionality to be present. Refer to that thread for more detail.

I think you just explained it more clearly, at least for me. I now understand better the referenced discussion.