Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)

Subject: Re: [boost] Common future base class (was Re: Boost.Fiber mini-review September 4-13)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-09-06 08:36:05

Le 06/09/15 14:09, Giovanni Piero Deretta a écrit :
> On Sun, Sep 6, 2015 at 1:34 AM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
> [snip
>> Giovanni, I'm all for adapting Boost.Thread to any global solution to this
>> problem.
>> What we need first is some one working on it, and showing that we are able
>> to efficiently implement when_all/when_any for some kind of future concept.
>> Then we can try to see how to make boost::future/std::future ...... models
>> of this concept.
>> If you have ideas on how this can work, a POC  and time, I propose you to
>> work on it and propose such a library to Boost.
>> I don't believe it is fair to add a link to a ongoing work implementation
>> during the review of a library having a different scope.
> hum, futures are in scope of a library that reimplements the c++11
> thread facilities on top of user space threads. My primary concern is
> that I wouldn't want to see in boost a proliferation of futures all
> slightly different and incompatible with each other. This being the
> second review in a row for a library that comes with its own futures,
> I would say that my concerns are well founded.
The problem exist already for any library proposing a standard future 
implementation. How can this new implementation works with a standard 
implementation. This is the case for Boost.Thread, HPX, Boost.AFIO, 
Boost.Fiber, or your own implementation.
What I meant is that we need to change the standard to be able to solve 
this problem, as the standard don't take it in account.
> To be clear, I'm not trying to sneak in a proposal for a library of my
> own: I have neither enough free time nor the permission of my employer
> to contribute a library to boost.
I suspected that this would be the case. We are all looking for free time.
> I was merely suggesting a *possible*
> implementation of the interoperation protocol.
I'm very interested in finding a solution to this interaction problem 
and I'll analyze any hint (but I will prefer non intrusive solutions 
that avoid forcing a specific implementation).
> My acceptance would be
> conditional on the library being interoperable with boost.thread, but
> not on the implementation.
This is up to you. I don't know what do you want as result of 
when_all/when_any with different implementations, even more when we have 
fiber/futures and thread/futures. What will be the semantics of this 
operation?
> I would prefer that the two futures types
> were physically the same or at least share part of the implementation
> though.
This could be done, if a solution to the interaction problem is 
satisfactory.

We could also share a common implementation between Fiber and Thread 
even if we don't have a solution to this problem. However we need a 
volunteer to do it.
Some issues to consider:
* Boost.Thread supports C++98 compilers, Boost.Fiber doesn't. The common 
implementation should be as complex as it is the current Boost.Thread 
implementation,
* Major temptation to redesign it with a high risk for regressions in 
Boost.Thread.

I will be ok for a C++14 implementation that a new Boost.Thread version 
can use however.
>
> Also, I'm not trying to get you to do the work of adding the missing
> functionality to boost::thread::future. That would probably be the
> responsibility of whoever is proposing a new library, but they would
> need your approval, as you are the current maintainer of boost.thread.
>
>
Glad to hear that ;-)

Best,
Vicente