Re: [boost] Executor associated to the future continuations (was [thread] boost::future::then)

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 https://svn.boost.org/trac/boost/ticket/11717 to track this 
feature request

Vicente