First provide in addition a static polymorphic interface. The template functions submit_at and submit_after would accept any chrono `time_point` and `duration`.

Is this with respect to the granularity of the time point? e.g. nano/micro/mille etc? If it is I'm assuming this would take an executor and then convert the time point to the desired granularity (nanoseconds by default) then add it to the executor.

Second, provide an adaptor that wraps an scheduled executor and makes it a polymorphic one.

Polymorphic with respect to what?

Third, provide an adaptor that wraps an executor, manage the time based operations using a specific thread and forward all the operations to the wrapped executor.

So this would take a reference to an executor or a shared_ptr then spawn a single thread that would loop and add the submitted closures at the desired time to the given executor? Ian, ________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Vicente J. Botet Escriba [vicente.botet@wanadoo.fr] Sent: Friday, March 14, 2014 3:34 AM To: boost@lists.boost.org Subject: Re: [boost] [Boost.Thread][GSoC] Boost.Thread executors proposal Le 13/03/14 04:59, Ian Forbes a écrit :

Hi,

Here is my GSoC proposal for working on the scheduled executors classes. It can be found here: www.cs.mcgill.ca/~iforbe/

This proposal mainly deals with the implementation of classes extending the `scheduled_executor` interface. I have already written thread pool implementations with very similar functionality to the ones proposed.

I feel that the current proposal could use a little bit of touching up so please feel free to leave comments/criticisms.

I would also be willing to take on any other work related to executors such the the dynamic/work-stealing thread pool implementation or the parallel algorithms library and add it into my proposal.

Hi, I like your proposal on scheduled_executor and possibly extend it to a priority thread pool. I would let the work-stealing outside the proposal. Just to note that the closure would not be a std::function as this class doesn't accept a movable only function. Boost.Thread would include (version 1.56) a boost::executors::work as a type-erased class for closures. I'm looking for a different approach respect to scheduled work of the N3785 proposal. First provide in addition a static polymorphic interface. The template functions submit_at and submit_after would accept any chrono `time_point` and `duration`. Second, provide an adaptor that wraps an scheduled executor and makes it a polymorphic one. Third, provide an adaptor that wraps an executor, manage the time based operations using a specific thread and forward all the operations to the wrapped executor. What do you think of this approach? Best, Vicente _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost