Re: [boost] [thread] boost::future::then

Subject: Re: [boost] [thread] boost::future::then
From: Mikael Olenfalk (mikael.olenfalk_at_[hidden])
Date: 2015-10-09 10:16:51

On Fri, Oct 9, 2015 at 3:44 PM, Vladimir Prus <vladimir.prus_at_[hidden]>
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.

> 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