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: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-10-29 09:34:47

On 29-Oct-15 4:09 PM, Vicente J. Botet Escriba wrote:

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

Yes, that would make sense. I found it a tad confusing that a concept requires some methods that I'd have to call
myself. Usually, a concept requires only the method that the library will actually call.

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

Thanks.

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

You're welcome. In the meantime, I'll try to make my example  into more reusable code. While Qt has QFuture, it has no 
continuation, which is sad.

-- 
Vladimir Prus
http://vladimirprus.com