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