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.