Boost logo

Boost :

Subject: Re: [boost] [GSoC] Scheduled Executors beta 1 release
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-07-26 16:09:04

On 26/07/2014 03:02 p.m., Ian Forbes wrote:
>>> This defaults to `boost::chrono::steady_clock`. There is a static assert to ensure that `Clock` is steady.
>> Given that you restrict everything to steady clocks, What's the
>> rationale for restricting to a single `time_point` instantiation only?
>> Furthermore, restricting to a single `duration` makes absolutely no
>> sense. Any `duration` can be mapped to a steady `time_point` and still
>> meet the timing specifications.
> This seems to be a popular request. I will look into it.

I am not surprised. Note that proper Chrono support is trivial for any
Clock for all your timed operations but some of those involving a

You may wanna read the following
. It was partly motivated by the poor choices made by the executors

>>> This is also satisfied by `high_resolution_clock` (...)
>> It is not.
>>> (...) is no longer a factor like with `steady_clock` and `high_resolution_clock` which are wall clocks.
>> They are not (or may not be). The only guarantees are that
>> `system_clock` represents a wall clock, `steady_clock` represents a
>> clock that may not be adjusted, `high_resolution_clock` represents a
>> clock with the shortest tick period. In particular, `steady_clock` and
>> `high_resolution_clock` may be aliases for other clocks.
> It's not guaranteed but I would assume it is steady for most modern machines.

Sorry, but that's not how it works. You can't base your work on
assumptions nor observations, only guarantees. In particular, your
observations don't hold for other platforms; and then there's the broken
platforms where clocks pretend to be steady when in reality they are not.

You have already correctly identified that any implementation has to be
based on a steady clock (kudos! the executors proposal got this wrong).
Once you have a steady clock, you can support timed operations for all
`duration`s, and all `time_point`s of any other steady clock. In order
to support `time_point`s of non-steady clocks too, it would be enough to
meet the standard timing specifications to wrap the closure into a
helper task that checks if the timeout is already satisfied, and
reschedules the closure otherwise (this may not be trivial, I haven't
looked at your implementation in detail).

There is one and only one standard clock that is guaranteed to be
steady, and that is the `steady_clock`. Build your implementation on top
of it. Don't provide the user a way to specify the implementation Clock,
provide the proper interface instead. If there happens to be a better
choice than `steady_clock` for a particular platform (I'm not saying
there is), and said clock is **guaranteed** to be steady, then the
decision to use it should belong to the library and not the user.


Agustín K-ballo Bergé.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at