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/b8db8fef8b28414d16c66761badc1c6fca...
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
Le 29/10/15 11:13, Vladimir Prus a écrit : 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