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

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. 

Ian,