Boost logo

Boost :

Subject: Re: [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 10:58:25

Le 10/10/15 15:26, Vicente J. Botet Escriba a écrit :
> 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
> make_ready_future/make_exceptional_future.
> 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.
I've create to track this
feature request


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