Le 06/11/15 08:35, Gavin Lambert a écrit :
On 29/10/2015 23:01, Vicente J. Botet Escriba wrote:
Le 29/10/15 10:14, Vladimir Prus a écrit :
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.
Admittedly I'm not very familiar with the Concurrency TS, but I think the reason that continuations are supposed to be executed via the inherited executor by default is for the marshal-back-to-main/UI-thread case when handing off background work.
In the case where background work is itself registering further continuations, then the background thread is supposed to be running a more generalised executor which can allow synchronous execution (eg. the executor's policy says "must run on one of these threadpool threads", and you happen to already be running on one of those threads, or "can run on any thread").
This is similar behaviour to ASIO's io_service::dispatch.
I don't think trying to decide this at the time the promise is made ready is the right choice. Unless I'm just misunderstanding what you're referring to here.
You misunderstood it. The launch::sync policy is usable with future::then() f.then launch::sync, next); Here next continuation will be executed on the same thread that will make ready the future. Vicente