Subject: Re: [boost] [GSoC] Scheduled Executors beta 1 release
From: Ian Forbes (ian.forbes_at_[hidden])
Date: 2014-07-26 14:29:11
>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.
This describes the scheduling_adaptor class.
Since there are no virtual methods the addition of template functions is possible.
>Note that your base class scheduled_executor is not an executor at all.
Perhaps I should move this into detail then.
I could also change the name to scheduled_executor_base and perhaps then change scheduling_adaptor to scheduled_executor.
This however would rule out any possible use of the scheduled_executor class a polymorphic base class since it would be hidden in detail.
>This has several advantages:
> * The time scheduled operations are available for all the executors.
This is provided via the scheduling_adaptor class.
> * The template functions could accept any chrono::steady_clock::time_point or any chrono::duration.
I can add template functions to do this. Others have requested this.
> * The non-time scheduled task don't pay for the additional cost to manage with a priority queue.
I can override (non-virtually) the submit(work) function in scheduling_adaptor to do this.
This however will complicate to ability to use the scheduled_executor polymorphically as calls though
scheduling_adaptor will avoid the queue while calls through a scheduled_executor& will put the task at the front/top.
Both will have the same behaviour but one will go through the queue.
Although it was never my intention of have this polymorphic behaviour it was a nice consequence of my design.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk