On Sun, Sep 6, 2015 at 1:34 AM, Vicente J. Botet Escriba
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. 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 was merely suggesting a *possible* implementation of the interoperation protocol. My acceptance would be conditional on the library being interoperable with boost.thread, but not on the implementation. I would prefer that the two futures types were physically the same or at least share part of the implementation though. 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. -- gpd