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-26 01:14:42

Le 25/07/14 11:10, Rob Stewart a écrit :
> On July 24, 2014 9:57:39 PM EDT, Ian Forbes <ian.forbes_at_[hidden]> wrote:
>> Hello,
>>
>> I am working on implementing scheduled executors as part of GSoC 2014
>> and am ready to announce my beta 1 release.
>> For more information on my project please see my original proposal at
>> www.cs.mcgill.ca/~iforbe
>> All my work is currently on this branch of boost.thread.
>> https://github.com/BoostGSoC14/boost.thread.executors .
>> I have written a fairly extensive README  about design and
>> implementation on this page.
>
>> I'm mostly interested in people reading this part of the README:
>> https://github.com/BoostGSoC14/boost.thread.executors#possible-changes--rfcs
>> This details possible changes that could be made and I would like some
>> feedback on them as these items have both pros and cons.
> Extra clock flexibility seems nice, but it forces templates. You don't mention any rationale for using templates versus the ABC design in the SG proposal, but this may be the reason. The argument in favor of binary compatibility is a good one, though shared_ptr solved that for deleters, so there may be some middle ground. Still, the question is what clock flexibility buys users. A CPU clock is trivial to retrieve, but is it significantly faster or less contentious than, say, steady_clock? Any resolution increase is questionable since thread scheduling and synchronization are already involved. As computers get faster, the resolution may matter, but steady_clock's resolution isn't fixed, so it can change with the hardware anyway. I guess I'm favoring the simplicity of picking one clock type and calling it good.
>
>
Hi,

The approach I have in mind for this library respect to scheduled work 
of the N3785 proposal is quite different. Instead of adding the 
scheduled operations to a specific scheduled_executor polymorphic 
interface, I opted by adding two member template functions to a class 
scheduled_executor that wraps an existing executor. This 
scheduled_executor will probably have a thread to take of the time 
scheduled operations, but this is not necessary. The semantic of the 
time scheduled operations is a little bit different. The task will be 
submitted to the associated executor at/after the given time_point/duration.

Note that your base class scheduled_executor is not an executor at all.

This has several advantages:

* The time scheduled operations are available for all the executors.
* The template functions could accept any 
chrono::steady_clock::time_point or any chrono::duration.
* The non-time scheduled task don't pay for the additional cost to 
manage with a priority queue.

One of the liabilities could be
* time scheduled task take more time and resources as they go possibly 
into two queues.

     template <class Executor>
     class scheduled_executor
     {
     Executor& ex;
     public:
       typedef  executor::work work;

       scheduled_executor(scheduled_executor const&) = delete;
       scheduled_executor& operator=(scheduled_executor const&) = delete;

       Executor& underlying_executor();

       void close();
       bool closed();

       void submit(work&& closure); // using directly the underlying 
executor
       template <typename Closure>
       void submit(Closure&& closure); // using directly the underlying 
executor

       template <class Duration>
       void submit_at(chrono::time_point<chrono::steady_clock,Duration> 
abs_time, work&& closure); // using the underlying executor once the 
time point has been reached

       template <class Rep, class Period>
       void submit_after(chrono::duration<Rep,Period> rel_time, work&& 
closure); // using the underlying executor once the duration has been 
elapsed

     };

I'm not saying that implementing scheduled executors directly as you 
propose has no use case, I'm just presenting an alternative and 
orthogonal design.

Best,
Vicente