Le 09/10/15 09:43, Vladimir Prus a écrit :
Hi,
looking through docs for some other futures implementation [1], I see this:
Why not use boost::future? #
At the time of writing, 1.53 (the first version with the requisite features) was brand new, not well-tested, and not available to [...] developers. It is still a bit buggy/bleeding-edge They haven't fleshed out the threading model very well yet, e.g. every single then currently spawns a new thread unless you explicitly ask it to work on this thread only, and executor support was nonexistent (and now, is still experimental).
Now, 1.53 is ancient. Can anybody comment on these statements regarding boost::future::thread state in 1.59?
The comment should be almost right, the first implementations had a lot of issues. Even in 1.59 the feature is broken (at least respect to what the standard TS Concurrency says) as the future resulting from ::then() blocks. If you admit that the resulting futures blocks the develop branch is OK for you (which includes some fixes respect to 1.59). I have a branch (https://github.com/boostorg/thread/tree/feature/non_blocking_futures) that don't blocks on any future, but this will break async. I have another branch that has copyable executors and non-blocking futures (https://github.com/boostorg/thread/tree/feature/make_executors_copyable). I expect to have this branch merged for 1.60.
In particular, suppose I have this:
// Thread 1
boost::promise<int> pi; boost::future<int> fi = pi.get_future();
// pass pi to thread 2 somehow
fi.then(....);
// Thread 2
pi.set_value(100);
And I want continuation to be executed in thread 1, assuming that thread 1 runs Qt event loop, allowing me to use QTimer::singleShot, or queued signal, or similar mechanism. How would I go about making boost::future do it? Has anybody done so?
You need the Executor interface. ::then(ex, f); http://www.boost.org/doc/libs/1_59_0/doc/html/thread/synchronization.html#th... Vicente