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 09:09:19

Le 29/10/15 11:13, Vladimir Prus a écrit :
> On 29-Oct-15 12:49 PM, Vicente J. Botet Escriba wrote:
>> Le 29/10/15 10:08, Vladimir Prus a écrit :
>>> On 11-Oct-15 9:30 PM, Vicente J. Botet Escriba wrote:
>>>> Le 10/10/15 16:58, Vicente J. Botet Escriba a écrit :
>>>>> Le 10/10/15 15:26, Vicente J. Botet Escriba a écrit :
>>>>>> Le 10/10/15 07:57, Vladimir Prus a écrit :
>>>>>>>
>>>>>>> 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
>>>>>
>>>>>
>>>> This commit contains a fix for this issue as well as the addition 
>>>> of the VERY-EXPERIMENTAL promise::set_executor and
>>>> packaged_task::set_executor. These should be replaced by 
>>>> constructors having an executor as parameter.
>>>>
>>>> https://github.com/boostorg/thread/commit/b8db8fef8b28414d16c66761badc1c6fcadfc38f 
>>>>
>>>
>>> Vicente,
>>>
>>> I've created a very early experiment, here:
>>>
>>>     https://gist.github.com/vprus/3a7bea25e4c0a0e4222d
>>>
>>> Does it look generally right for you?
>> I don't know Qt. It seems ok beside tht fact that you create an 
>> Executor for each Task. Maybe this is not important for
>> you as your Executor class is adapting Qt.
>
> It's not hugely important, since in practice the work performance is 
> orders of magnitude longer
> than QObject creation. Anyway, I possibly can create an executor per 
> thread on demand, and reuse them.
Don't worry with the new version where you will give the Executor at 
promise creation the cost will be minimal in your case.
>
>>> I'm worried that Executor interface requires methods like
>>> close/closed,
>> This is used to shutdown smoothly the worker threads.
>
> So where will ::close be called? Is it ever called from boost::thread? 
> That seems unlikely, since boost::thread
> does not know at which point I no longer need an executor. And if 
> boost::thread does not call this,
> why am I required to implement this method at all?
Some executors call close in the destructor before joining all the threads.
In addition the use can request to close the submission of new work.

If needed we can move this also to another Executor layer, so that 
Executors can be created without close()/closed().
>
>>> try_executing_once and reschedule_until that don't seem documented 
>>> in detail.
>> These should be put in another concept refining executor. I will try 
>> to do it for 1.61.
>>> Is
>>> it fine to leave them undocumented in my case?
>>>
>> Well, I don't know what do you mean by undocumented and in your case. 
>> Document for what?
>
> I meant 'unimplemented' - will try_executing_once and reschedule_until 
> be ever called in
> my case? If not, which you seem to indicate above, then everything is 
> fine.
>
Right, these functions are not called of you don't call them. So for the 
time been and as the executor interface requires them, you can just 
implement them as you did.

I will create 3 tickets:
* Add launch:sync policy
* Extract close/closed to a more specific shutdonw-executor interface.
* Extract try_executing_one, reschedule_until to a more specific 
reentrant executor interface.

Glad to have a user that push me to improve the library :) Well, at 
least this is what I believe I'm doing.

Best,
Vicente