On Fri, Oct 9, 2015 at 3:44 PM, Vladimir Prus
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.
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. Also it seemed to me that it actually didn't compile in VS2015 (which is what I use). My guess is that it is very much still experimental code. If you play with it some more I am very interested in your findings. 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? /M