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-29 08:55:36

Le 29/10/15 11:21, Vladimir Prus a écrit :
> On 29-Oct-15 1:01 PM, Vicente J. Botet Escriba wrote:
>> Le 29/10/15 10:14, Vladimir Prus a écrit :
>>> On 17-Oct-15 7:41 PM, Vicente J. Botet Escriba wrote:
>>>>
>>>> Hi again,
>>>>
>>>> I believe that it would be better if the use states explicitly that 
>>>> she wants to inherit the policy unsing a specific
>>>> policy
>>>>
>>>>      f.then(launch::inherit, cont);
>>>>
>>>> I have not implemented this already, but I have already the 
>>>> possibility to use the undocumented executor policy
>>>>
>>>>      f.then(launch::executor, cont);
>>>>
>>>> This would launch cont using the inherited executor.
>>>
>>> I suppose I can implement QtFuture that:
>>>
>>> - Holds boost::future and a pointer to my executor
>>> - Has .then method (or better yet, overrides the >> operator)
>>> - Calls boost::future::then with whatever parameters
>>>
>>> From the code above I'm not sure what
>>>
>>>     f.then(launch::inherit, cont);
>>>
>>> would do? Launch using the executor that was specified in promise?
>> Yes.
>>> It would seem, really, that if an executor was specified in promise, 
>>> then using that executor should be default?
>> Well, this is now the default behavior as it corresponds to what was 
>> documented.
>>
>> However I believe that the default behavior shouldn't be to inherit.
>> I want to be able to execute the continuation synchronously by the 
>> thread that made ready the promise.
>> I have added an experimental flag BOOST_THREAD_CONTINUATION_SYNC that 
>> switch the default behavior.
>> Alternatively I could add a launch::sync policy  (and I will do it).
>> So the single thing that will remain is to decide what is the default 
>> behavior.
>
> I see. I've only started to play with this code, so can't yet voice a 
> strong opinion either way.
>
>> Volodya, if you use this in production code, please, be ready to have 
>> changes in the next release.
>> There will be no promise::set_executor. You will need to give the 
>> executor at the creation of the promise, as it was
>> planned from the beginning (See that the set_executor has not been 
>> documented and that the ticket is still open. It is
>> just that this need to refactor the core more deeply. The advantage 
>> is that you will not need anymore to allocate the
>> future (no type erasure needed).
>
> Thanks for the warning - I don't use it in production at present. 
> Passing executor when creating a promise is also fine
> with me. Will it still be possible to pass an explicit executor to 
> ::then?
>
>
Of course.

Vicente