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

Subject: Re: [boost] [GSoC] Scheduled Executors beta 1 release
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-07-27 03:32:47

Le 26/07/14 22:09, Agustín K-ballo Bergé a écrit :
> 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.
Thanks for this pointer. Really very interesting.

There is a type here
   auto d = 
std::chrono::conversion_cast<std::chrono::nanoseconds>(rel_time);
>
>>>> 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.
>
+1 for all your remarks.

Vicente