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

...

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

On Sun, Sep 6, 2015 at 1:34 AM, Vicente J. Botet Escriba wrote: [snip 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

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

Le 06/09/15 14:09, Giovanni Piero Deretta a écrit : this problem, as the standard don't take it in account. 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