CODEWITHSUNDEEP
c++c++11concurrencyfuture
Curious
Curious

Reputation: 21510

Why are executors not in Concurrency TS and in the std::future interface anymore?

The interface for std::future::then in the paper N3784 included an overloaded version that accepted an executor (described more here in N3562) as a parameter. So if you wanted more control over which thread the callback was executed on you could do so.

But the official document that goes over all the features that are in the concurrency TS here http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.unique_future does not include that overload for .then() and doesn't mention executors at all. It says

When the object's shared state is ready, the continuation INVOKE(DECAY_COPY(std::forward<F>(func)), std::move(*this)) is called on an unspecified thread of execution with the call to DECAY_COPY() being evaluated in the thread that called then.

Why does the interface not offer precise control of how the closure is executed? How then can one exercise control over which thread runs the callback? Why the change from the proposed version?

Note I am not sure if the concurrency TS paper I linked to is the latest one, but cppreference does not mention executors anywhere either

Edit If someone has a reference or reason in some C++ standards paper that mentions the reason for not continuing with executors, that would be great!

Upvotes: 5

Views: 1963

Answers (1)

Adrian McCarthy
Adrian McCarthy

Reputation: 47962

Why the change from the proposed version?

The TSes are trial balloons for features approaching standardization but may not be in final form yet. They are a chance for the standards committee to get experience to see what does and doesn't work in the real world.

Since there is at least one newer proposal for executors, it seems the working group wasn't satisfied with executors as they were in the TS and are refining them before standardization.

How then can one exercise control over which thread runs the callback?

Right now, it seems you'd have to depend on a language or library extension or roll your own. I haven't studied the proposal enough to say how you would do it if the proposal becomes part of the standard, but it looks like then_execute, which can be a free function or a member of the executor object, would be the key.

Upvotes: 2

Related Questions