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

Subject: Re: [boost] [GSoC] Scheduled Executors beta 1 release
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-07-25 05:10:53

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.

Your queue is flawed: what if T's copy constructor is invoked when calling pull(), and it throws an exception? Also, pull() is conventionally called "pop".

>There is an abstract class scheduled_executor that deals with all the
>enqueue methods to the executor. The ctor is protected. There are no
>virtual members.

The class isn't abstract since it has no virtual member functions. It is simply a base class.

>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.

An exception seems appropriate when trying to enqueue a task on a closed executor.

Your queue class should either be a full fledged, fully tested class, or it should be in detail. The former is out of scope for your project despite its desirability.

You don't describe priority_executor, but I assume it would prioritize based upon arbitrary priority rather than on time. That should be easy to implement and I can imagine use cases for that, so it seems like a worthwhile addition if time permits.

___
Rob

(Sent from my portable computation engine)