Boost logo

Boost :

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.


> 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

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