Le 09/10/15 16:16, Mikael Olenfalk a écrit :
On Fri, Oct 9, 2015 at 3:44 PM, Vladimir Prus
wrote: On 09-Oct-15 4:02 PM, Mikael Olenfalk wrote: ...
I might have misunderstood the question but I would assume a solution would be to build boost.thread with executors enabled[1]. And then wrap the QT event loop in an executor interface[2] and use the boost::future<T>::then(Executor&, ...) overload.
Mikael,
thanks for the response. I suppose it would work - although if I need to pass this executor any time I call 'then', it become rather awkward rather quickly. It would be nicer if promise could have an executor, and pass it to future and then to futures returned by 'then', so that I only need to to specify custom behaviour when creating a promise - that can be easily wrapped in a function.
I don't think so, I had a very quick look but didn't see anything. See my replay to Vladimir.
Do you have any comments on presence or absence of bugs, and overall API maturity? Having to define macros to get useful functionality is not quite perfect.
I have barely played with it, I got little bit discouraged on using it at work as it required enabled undocumented feature macros. Please, next time you find things like that please post on this ML or create a ticket. Anyway, I'm sure that there are a lot of error in the documentation. What is not documented for you? Also it seemed to me that it actually didn't compile in VS2015 (which is what I use). You know I started this some time ago and deliver the first version for boost 1.53 (if Vladimir is right). Since then, there have been a lot of compiler versions that have been released. We do as much as possible to write portable code, but no MSVC version is satisfactory, there is always some feature missing or not working completely.
I'm afraid but since more than 3 years I don't have a Windows machine to develop, so I can just try and see what the regression said me. You can see the results on http://www.boost.org/development/tests/develop/developer/thread.html. The results are no so bad for MSVC. There are some lambda issues.
My guess is that it is very much still experimental code. All the executor stuff is really experimental and I have plans to change a little bit the interface to adhere to the Concurrency TS (once they decide the interface).
If you play with it some more I am very interested in your findings. Me too ;-) If you also happen to figure out how to combine it with boost::asio::io_service I would be very interested in hearing your findings, we have a (global) worker-pool-thingie at work which uses io_service and I would like to make boost::async(Executor& ex, C...) work with it so that usage becomes nicer/simpler.
I guess the author of Boost.Thread is hanging out on this mailing list, maybe (s)he can comment on status?
Here I am. Vicente