Re: [boost] [GSoC] Scheduled Executors beta 1 release

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 
`sync_timed_queue`.

You may wanna read the following 
http://talesofcpp.fusionfenix.com/post-15/rant-on-the-templated-nature-of-stdchrono 
. It was partly motivated by the poor choices made by the executors 
proposal.

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

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com