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

Le 25/07/14 11:10, Rob Stewart a écrit :

On July 24, 2014 9:57:39 PM EDT, Ian Forbes 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_pointchrono::steady_clock,Duration abs_time, work&& closure); // using the underlying executor once the time point has been reached template void submit_after(chrono::duration 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