Boost logo

Boost :

Subject: [boost] Executor associated to the future continuations (was [thread] boost::future::then)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-10-10 09:26:06

Le 10/10/15 07:57, Vladimir Prus a écrit :
> On 09-Oct-15 10:49 PM, Vicente J. Botet Escriba wrote:
>> Le 09/10/15 15:44, Vladimir Prus a écrit :
>>> On 09-Oct-15 4:02 PM, Mikael Olenfalk wrote:
>>>> On Fri, Oct 9, 2015 at 9:43 AM, Vladimir Prus
>>>> <vladimir.prus_at_[hidden]>
>>>> wrote:
>>>>> In particular, suppose I have this:
>>>>> // Thread 1
>>>>> boost::promise<int> pi;
>>>>> boost::future<int> fi = pi.get_future();
>>>>> // pass pi to thread 2 somehow
>>>>> fi.then(....);
>>>>> // Thread 2
>>>>> pi.set_value(100);
>>>>> And I want continuation to be executed in thread 1, assuming that
>>>>> thread 1
>>>>> runs Qt event loop,
>>>>> allowing me to use QTimer::singleShot, or queued signal, or similar
>>>>> mechanism. How would I go
>>>>> about making boost::future do it? Has anybody done so?
>>> ...
>>>> I might have misunderstood the question but I would assume a
>>>> solution would
>>>> be to build boost.thread with executors enabled[1]. And then wrap
>>>> the QT
>>>> event loop in an executor interface[2] and use the
>>>> boost::future<T>::then(Executor&, ...) overload.
>>> Mikael,
>>> thanks for the response. I suppose it would work - although if I
>>> need to pass this
>>> executor any time I call 'then', it become rather awkward rather
>>> quickly.
>> Well this is the current interface :)
>>> It would
>>> be nicer if promise could have an executor, and pass it to future
>>> and then
>>> to futures returned by 'then', so that I only need to to specify
>>> custom behaviour
>>> when creating a promise - that can be easily wrapped in a function.
>> If your future is created with
>> auto f = async(ex, fct)
>> then the call to
>> f.then(fct2);
>> would use the same executor ex.
> Vicente,
> thanks, that's good to know. What if I don't want to use async, but
> rather create promise/future
> directly? Can I specified executor when creating future?
Not now. The executors interface is experimental, so we can consider
adding a way to associate a future to an executor.
The sources of a future are promise, packaged task, async and

I've not though too much on it but I believe that it is better to
associate the Executor interface to the source instead of changing it
directly on the future even if this multiplies the interfaces. This is
because I would need to associate the Executor at creation time.

I'm not for providing a set_executor function, as this would imply that
the shared state must always be aware of a possible executor and so the
Executor should be type-erased which is more costly than needed.

We could add a set_executor function, but this function will work only
if the shared state is allocated lazily, which I(m not sure it is
mandated by the standard.

> Suppose I'm in UI thread, and I ask backend thread to do something. I
> would like for the work to
> be done in backend thread, and then for all continuations to be
> executed in UI thread. Or, more
> generically, in whatever thread has initialized the operation.
I understand your use case, but what is wrong wrapping the back-end task
with the executor that initialized it and use this executor every time
you need it.

> So, if I implement a "run in UI thread" executor, I don't want
> async(ex, fct) to execute fct in
> UI thread.
async(ex, fct) will be executed on the thread(s) associated to ex, not
the current thread. What am I missing.
> So, the function must be executed in different thread from all the
> continuations,
> and it would seem I'd need to something set executor on promise for
> that to work?

I will see how adding an Executor parameter to promise, packaged_task
constructors and make_ready_future/make_exceptional_future could be
implemented if this will solve your use case.


P.S. Maybe Harmut, Thomas Heller or Agustín Bergé have already some
experience with his HPC library.

Boost list run by bdawes at, gregod at, cpdaniel at, john at