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


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