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

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

Best,
Vicente

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