Futures Review Starts Today - January 5, 2009
Futures Review Starts Today - January 5, 2009 Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Please review one or both libraries for submission to boost. Apparently, Anthony Williams' submission has also been sumbitted the C++ standards committee. Status unknown. As always, here are some questions you might want to answer in your review(s): What is your evaluation of the design(s)? What is your evaluation of the implementation(s)? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library(s)? Did you try to use the library? With what compiler(s)? Did you have any problems? How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? Do you think the libraries should be accepted into Boost as-is or should they be merged? Apparently, there has been various discussions about these two libraries last six months. The authors will need to bring us up to date as to why they want their libraries to be reviewed seperately. Also, each author should evaluate each others library and point out the differences in their implentations. These will serve as useful discussion points. The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result. As always, your reviews will certainly assist the authors in improving their libraries even further. Thank you in advance. Please feel free to participate in any discussion even if your not going to provide a full review. Review Manager Tom Brinkman
I'm refering to the updated version of Anthonys library at http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html because http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp seams not to be up-to-date (missing some functionality like lazy futures)!
What is your evaluation of the design(s)? What is your evaluation of the implementation(s)?
Both libraries are good designed and provide: - value transfer - exception transfer (Braddock uses its own exception_ptr implementation) - lazy futures (result is not actually computed until it is requested via future::get() ) - a wrapper class for wrapping callable objects (future_wrapper, packaged_task) Task chaining - Braddocks implementation provides a callback mechanism if the future becomes ready (result was set). This allows chaining of tasks (used in boost.threadpool). This functionality seams not to be provided by the lib from Anthony. Wait callbacks are provided only by Anthonys implementation. Move semantics are only provided by Anthonys lib.
What is your evaluation of the documentation?
Content of both documentations is sufficient - Braddock doesn't conform to the boost documentation style (Quickbook/Boostbook).
What is your evaluation of the potential usefulness of the library(s)?
Both libaries are useful and share same functionality but also provide additional functionality (ready callback, wait callback, move semantics).
Did you try to use the library? With what compiler(s)? Did you have any problems?
I used Braddocks library and the N2561-future (old one) library. Linux, FreeBSD 7.0 -> gcc-4.3 OpenSolaris -> gcc-4.2 Windows XP Prof -> vc-9.0
How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study?
maybe you can say in-depth
Do you think the libraries should be accepted into Boost as-is or should they be merged?
The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result.
The library provided by Anthony seams to be more feature complete and the interface should be more conform to the future C++0x standard. Thatswhy I would vote for Anthonys lib if completion callbacks (future result was set -> task chaining) are provided. regards, Oliver -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Hi, ----- Original Message ----- From: "Tom Brinkman" <reportbase@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 2:25 AM Subject: [boost] Futures Review Starts Today - January 5, 2009
Futures Review Starts Today - January 5, 2009
Braddock Gaskill http://braddock.com/~braddock/future
Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp
As Anthony has poste to this ML
The latest version of that library is at:
Docs: http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html Code+Docs: http://www.justsoftwaresolutions.co.uk/files/n2561_futures_revised_20080530....
Anthony --
Please review one or both libraries for submission to boost. Apparently, Anthony Williams' submission has also been sumbitted the C++ standards committee. Status unknown.
Anthony Williams' submission has been accepted (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2627.html) and included in the N2798 Working Draft, Standard for Programming Language C++ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf Section 30.5. As I have already say on a post responding to "Re: [boost] Futures - Reviews Needed (January 5, 2009)" (without any response neither from you neither from the authors), this is the first time we review a library that has a corresponding accepted standard for C++0x. IMO any Future Boost library should at least provide the current C++0x Future accepted standard and use the Boost.Exception library as mechanism to transport the exceptions. Other libraries that should be used are Boost.Chrono and Boost.Move, but these are not yet even in the schedule queue. Once we have an implementation of the standard interface we can see how other features can be implemented on top of this interface. Neither Braddock nor Anthony implements the C++0x accepted interface even if the Anthony is much closer. But Anthony Williams has already an implementation of the C++0x Future on his comercial just::thread library (http://www.stdthread.co.uk/forum/index.php?topic=64.0). Anthony, I would prefer you propose for review the n2627 interfacce. Why do you propose for review un interface that is outdated? It seems to me a lost of time.
Apparently, there has been various discussions about these two libraries last six months. The authors will need to bring us up to date as to why they want their libraries to be reviewed seperately.
I have no see any message from Braddock since a long time. Braddock are you still there?
Also, each author should evaluate each others library and point out the differences in their implentations. These will serve as useful discussion points.
I agree.
The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result.
As I have already say, any Future Boost library should at least provide the current C++0x Future accepted standard. Once we have an implementation of the standard interface we can see how other features can be implemented on top of this interface. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Anthony, I would prefer you propose for review the n2627 interfacce. Why do you propose for review un interface that is outdated? It seems to me a lost of time.
I wrote the code for the boost submission 8-9 months ago, in accordance with the then-current C++0x proposal (with a few extras) and it has been in the review queue since. I have since focused my energy on my commercial library, rather than on a library which may or may not be accepted into Boost, with or without changes (especially since there is a competing submission). If a futures library is accepted into Boost, I will gladly work with Braddock to update the library with any features required by the review, including conformance to N2627. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Just so that noone misses it, I submitted my review yesterday at http://www.nabble.com/Futures---Reviews-Needed-(January-5%2C-2009)-to2122184... Best Regards, Johan Torp www.johantorp.com -- View this message in context: http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tp2130... Sent from the Boost - Dev mailing list archive at Nabble.com.
Hi Anthony, Some minor implementation details: Why there is not other.future reset in shared_future(shared_future && other) { future.swap(other.future); } shared_future(unique_future<R> && other) { future.swap(other.future); } How the move is made? Is future.swap(other.future); other.future.reset(); more efficient than future.reset(other.future); other.future.reset(); ? Otherwise you can change it in: shared_future& operator=(shared_future && other) { future.swap(other.future); other.future.reset(); return *this; } shared_future& operator=(boost::detail::thread_move_t<shared_future> other) { future.swap(other->future); other->future.reset(); return *this; } shared_future& operator=(boost::detail::thread_move_t<unique_future<R> > other) { future.swap(other->future); other->future.reset(); return *this; } And once shared_ptr implements movable you could use future = move(other.future); Isn't it? Vicente
PING! ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 11:13 PM Subject: Re: [boost] Futures Review - minor implementation details
Hi Anthony,
Some minor implementation details: Why there is not other.future reset in shared_future(shared_future && other) { future.swap(other.future); } shared_future(unique_future<R> && other) { future.swap(other.future); }
How the move is made?
Is future.swap(other.future); other.future.reset(); more efficient than future.reset(other.future); other.future.reset(); ? Otherwise you can change it in:
shared_future& operator=(shared_future && other) { future.swap(other.future); other.future.reset(); return *this; } shared_future& operator=(boost::detail::thread_move_t<shared_future> other) { future.swap(other->future); other->future.reset(); return *this; } shared_future& operator=(boost::detail::thread_move_t<unique_future<R> > other) { future.swap(other->future); other->future.reset(); return *this; }
And once shared_ptr implements movable you could use future = move(other.future); Isn't it?
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Hi Anthony,
Some minor implementation details: Why there is not other.future reset in shared_future(shared_future && other) { future.swap(other.future); } shared_future(unique_future<R> && other) { future.swap(other.future); }
How the move is made?
These are the constructors. The "future" member is initially NULL, so the swap sets "other.future" to NULL whilst transferring the value from "other.future" to "this->future"
Is future.swap(other.future); other.future.reset(); more efficient than future.reset(other.future); other.future.reset(); ? Otherwise you can change it in:
The former avoids incrementing any reference counts. The latter has to increase the reference count on *other.future just to decrease it again with the reset.
And once shared_ptr implements movable you could use future = move(other.future); Isn't it?
Yes. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 20, 2009 12:40 PM Subject: Re: [boost] Futures Review - minor implementation details
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Hi Anthony,
Some minor implementation details: Why there is not other.future reset in shared_future(shared_future && other) { future.swap(other.future); } shared_future(unique_future<R> && other) { future.swap(other.future); }
How the move is made?
These are the constructors. The "future" member is initially NULL, so the swap sets "other.future" to NULL whilst transferring the value from "other.future" to "this->future"
OK, I see.
Is future.swap(other.future); other.future.reset(); (1) more efficient than future.reset(other.future); other.future.reset(); ? Otherwise you can change it in:
The former avoids incrementing any reference counts. The latter has to increase the reference count on *other.future just to decrease it again with the reset.
I see. Thanks, Vicente
Shouldn't future exceptions inherit from boost::exception in order to work with boost::throw_exception and be able to transfer these exception between threads? Vicente
AMDG vicente.botet wrote:
Shouldn't future exceptions inherit from boost::exception in order to work with boost::throw_exception and be able to transfer these exception between threads?
boost::throw_exception requires inheritance from std::exception, not boost::exception. In Christ, Steven Watanabe
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 11:38 PM Subject: Re: [boost] Futures Review - future exceptions and boost::exception
AMDG
vicente.botet wrote:
Shouldn't future exceptions inherit from boost::exception in order to work with boost::throw_exception and be able to transfer these exception between threads?
boost::throw_exception requires inheritance from std::exception, not boost::exception.
You are right. Vicente
On Tue, Jan 6, 2009 at 2:27 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Shouldn't future exceptions inherit from boost::exception in order to work with boost::throw_exception and be able to transfer these exception between threads?
Inheritance from boost::exception does not guarantee the ability to use current_exception/exception_ptr, throwing using boost::throw_exception or BOOST_THROW_EXCEPTION does (BOOST_THROW_EXCEPTION is preferable because it'll automatically capture the file/line location of the throw.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected? Vicente
AMDG vicente.botet wrote:
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected?
Why do you want to be able to inherit from futures? In Christ, Steven Watanabe
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 11:40 PM Subject: Re: [boost] Futures Review - inheriting from futures
AMDG
vicente.botet wrote:
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected?
Why do you want to be able to inherit from futures?
To extend their functionality. Vicente
AMDG vicente.botet wrote:
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected?
Why do you want to be able to inherit from futures?
To extend their functionality.
I'm afraid that the above statement is absolutely zero use to me. future is not a polymorphic class, so you don't have anything to override. Do you a specific use that cannot (easily) be implemented with the current interface? In Christ, Steven Watanabe
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, January 07, 2009 12:44 AM Subject: Re: [boost] Futures Review - inheriting from futures
AMDG
vicente.botet wrote:
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected?
Why do you want to be able to inherit from futures?
To extend their functionality.
I'm afraid that the above statement is absolutely zero use to me. future is not a polymorphic class, so you don't have anything to override.
We can inherit from a class that it is not polymorphic, of course we cannot use it polimorphicaly. There are a lot of clases that inherits from non polymorphic class in Boost. I can overrride any function in the class of course not polymorphycaly. I can also take the future as a member
Do you a specific use that cannot (easily) be implemented with the current interface?
I would like to have a minimal future class that do not have callbacks, and on top of this define a callback_future. I don't not want to pay for wat I dont use. Inheritance is a mechanism to achieve it. Best, Vicente
AMDG vicente.botet wrote:
In order to be able to inherit from futures, shouldn't the constructor(detail::future_object) or constructor(detail::future_impl) be protected?
Why do you want to be able to inherit from futures?
To extend their functionality.
I'm afraid that the above statement is absolutely zero use to me. future is not a polymorphic class, so you don't have anything to override.
We can inherit from a class that it is not polymorphic, of course we cannot use it polimorphicaly.
Of course we can.
There are a lot of clases that inherits from non polymorphic class in Boost.
Sure, but most public classes in Boost are not intended to be inherited from. I still don't see the need to inherit from an ordinary value type like future.
I can overrride any function in the class of course not polymorphycaly.
Technically, it's hiding not overriding...
I can also take the future as a member
So, why do you want inheritance?
Do you a specific use that cannot (easily) be implemented with the current interface?
I would like to have a minimal future class that do not have callbacks, and on top of this define a callback_future. I don't not want to pay for wat I dont use. Inheritance is a mechanism to achieve it.
Okay, but this requires a lot more than simply making a constructor public. Also, if you use inheritance, will it behave sensibly in the face of upcasting In Christ, Steven Watanabe
Tom Brinkman wrote:
Futures Review Starts Today - January 5, 2009
This is not a review. Maybe it's a "meta-review". One of the things that Boost tries to be is a proving-ground for things that are heading towards C++ standardisation. In this case it seems to have gone topsy-turvy: the C++ standards committee have approved an implementation of futures and now Boost is reviewing two libraries neither of which is an exact implementation of the standard proposal. This doesn't seem right to me. So: - The idea of futures looks useful and I think Boost should have it. - It would not be sensible to have anything other than something conforming to the proposed standard, except for any hacks necessary for pre-0x compatibility and perhaps for non-conflicting extra features. - I believe that both of the proposals were ready for review some time ago. I'm unsure of the exact chronology but I have the impression that if they had been reviewed by Boost more promptly then perhaps that review could have been available to the standards committee. - I understand that the slowness of the review queue is a result of too few review managers for too many proposed libraries. Assuming that the pool of review managers can't be pressed to give up more of their time, maybe the pool could be widened by relaxing the required qualifications: although reviews often require that the review manager does a lot of collating of opinions, I'm not aware of many cases where the essential accept/reject decision has been very difficult to make or is different from what a vote-count of reviewers would have said (though maybe I'm wrong). Alternatively maybe the other end of the problem should be fixed by attempting to limit the scope of contributions to focus more on "core" features that might one day end up in std::c++. Regards, Phil.
----- Original Message ----- From: "Phil Endecott" <spam_from_boost_dev@chezphil.org> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 11:44 PM Subject: Re: [boost] Futures Review Starts Today - January 5, 2009
One of the things that Boost tries to be is a proving-ground for things that are heading towards C++ standardisation. In this case it seems to have gone topsy-turvy: the C++ standards committee have approved an implementation of futures and now Boost is reviewing two libraries neither of which is an exact implementation of the standard proposal. This doesn't seem right to me. So:
- The idea of futures looks useful and I think Boost should have it.
I agree completly.
- It would not be sensible to have anything other than something conforming to the proposed standard, except for any hacks necessary for pre-0x compatibility and perhaps for non-conflicting extra features.
I agree again.
- I believe that both of the proposals were ready for review some time ago. I'm unsure of the exact chronology but I have the impression that if they had been reviewed by Boost more promptly then perhaps that review could have been available to the standards committee.
I think this was the intention of Anthony.
- I understand that the slowness of the review queue is a result of too few review managers for too many proposed libraries. Assuming that the pool of review managers can't be pressed to give up more of their time, maybe the pool could be widened by relaxing the required qualifications: although reviews often require that the review manager does a lot of collating of opinions, I'm not aware of many cases where the essential accept/reject decision has been very difficult to make or is different from what a vote-count of reviewers would have said (though maybe I'm wrong).
Where can we found the required qualifications of a review manager?
Alternatively maybe the other end of the problem should be fixed by attempting to limit the scope of contributions to focus more on "core" features that might one day end up in std::c++.
Which Boost libraries can not one day end up in std::c++? In any case I don't thik this limitation will be useful. Best, Vicente
Some background on myself to give context for this review: - Long-time user of boost in commercial C++ development - Making extensive use of threads and related constructs - Using home-brew future-like API for managing inter-thread communciations
What is your evaluation of the design(s)?
As others have noted, futures now appear in the draft C++ standard, and Anthony's API conforms closely to that (or, more correctly, the draft C++ standard appears to be based on Anthony's API). Unless I have some reason to think the draft C++ standard will completely change the proposed future API, I would tend to support Anthony's API. As Anthony has said in this thread, if conformance to the draft C++ standard future API is required for inclusion, he would help with that effort, for either API, which is fine with me. Design-wise, I prefer Anthony's API as it seems simpler to use; Braddock's API includes things of questionable value (to me). Specifically: - callbacks seem tricky to use/implement safely - future streams seem unnecessary at this point Braddock's API does try to address the notion of scheduling. One of the problems I've run into in using threads in C++ is that it is very important to treat threads as resources to be managed just like other limited OS resources. It generally isn't enough to say "oh, we'll just execute this on another thread"; this can often lead to a situation where you run out of threads, especially when thread execution can block. Scheduling, deciding when a thread can run (because futures that the execution is dependent on have become available), is a tricky notion in C++, because a thread blocked waiting for a future is taking up a limited resource, but without that thread waiting nothing will take action when the future does become available; Braddock's API tries to address this using callbacks. I don't think this is the correct approach. In C++ specifically, dealing well with threads requires care, by strictly limiting the number of threads being used and taking great care to avoid deadlocks and blocking among those threads; I don't think this is trivial. Thread-pools are probably the wrong general approach, though they may be appropriate in some contexts. It would be nice if some of the designs allowed for waiting on multiple futures; this would allow off-loading waiting for futures that looks hard to do in Anthony's API, but could possibly be done in Braddock's. Not sure if I'm explaining myself well here. In the product development I do, we often wind up dealing with situations where blocking a thread would cause lots of problems (specifically running out of threads), so there is typically a lot of additional complexity around ensuring that this doesn't happen.
What is your evaluation of the implementation(s)?
Anthony's implementation looks simple and straightforward; not much that I can say there. Braddock's is bigger, as goes with a bigger API. I'm glad that both APIs come with a test suite. As for Braddock's implementation, as I noted above, I'm not convinced of the need of the future stream. Implementation-wise, it seems complex. Based on Herb Sutter's recent forays into writing lock-free queues that perform well on modern multi-core hardware, I'm skeptical of the claim of "low lock contention" that the documentation makes. Note that I'm not against the concept of a future stream; I have implemented something similar in my application. Just don't think it needs to be part of the library.
What is your evaluation of the documentation?
Both seem complete. Overall I prefer Anthony's for succinctness, but it is a simpler API as well, which helps.
What is your evaluation of the potential usefulness of the library(s)?
As I said, I've implemented my own future-like API; having one available in boost would have been nice. There are many contexts that I would like to have one, every day :) Many jobs ago, I was introduced to futures (can't recall exactly; either through some beta version of Metrowerk's Powerplant library or on some MacHack CD, though I suspect the former), and have only started to see the concept pop up again in the last couple years. I'm pretty happy that they look to be coming into the C++ standard.
Did you try to use the library? With what compiler(s)? Did you have any problems?
Have not tried to use either.
How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study?
Somewhere in between...
Are you knowledgeable about the problem domain?
I'd like to think so, but I keep learning more and realizing that I don't know as much as I think I do... Having said that, my current thinking is that using threads effectively in C++ is difficult, and a lot of the reason for this is the programming model itself. I suspect that effective use of multiple processors/cores could be done better in interpreted languages (my favourite model probably being something like Rob Pike's Newsqueak). If starting a new C++ project today, assuming I was dealing with a high-performance, mission-critical app, I would be probably be structuring code with threading in mind, the goal being to keep a small number of threads busy with none of those threads blocking, with waiting (I/O, asynchronous waits, etc) happening on a small number of additional threads. I'd probably avoid using thread pools entirely, based on experience.
Do you think the libraries should be accepted into Boost as-is or should they be merged?
As discussed, now that there appears to be a proposal in the draft standard, I would expect boost to at least have a matching API. As Vincente noted, it strikes me as odd that C++0x already has an proposal for the API in the draft and we're trying to decide what will make it into boost. The only reason I can see for putting a future library into boost at this point is to gain experience with the API to provide feedback for the C++ standard, until C++0x is defined and available in popular compilers. Additional things (e.g., future streams, callbacks) could be added as new boost extensions to C++0x API, but they should then be re-worked to fit that API... IMHO... Cheers Oliver Seiler
Hi, My use case is a function that request an asynchronous executor to fork all the functions given as parameter and returns a quite complex type template< typename AE, typename F1, ..., typename Fn> typename result_of::fork_all<AE, fusion::tuple<F1,..., Fn> >::type fork_all( AE& ae, F1 f1, ..., Fn fn ); and used as follows: bith::launcher ae; typedef bith::result_of::fork_all<bith::launcher ,boost::fusion::tuple<int(*)(),int(*)()> >::type auto_type; auto_type handles= bith::fork_all(ae, simple_thread, simple_thread); For a launcher asynchronous executor, result_of::fork_all<AE, fusion::tuple<F1,..., Fn> >::type is a boost::fusion::tuple<unique_future<result_of<Fk() ...>. If we register unique_future on the Boost.Typeof library, we are able to write BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread)); which is much simpler. Next follows the contents of the file. Could this file be added to the Boost.Future librarie? Thanks, Vicente ==================== // boost/futures/typeof/future.hpp #ifndef BOOST_FUTURES_TYPEOF_FUTURE__HPP #define BOOST_FUTURES_TYPEOF_FUTURE__HPP #include <boost/futures/future.hpp> #include <boost/typeof/typeof.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() BOOST_TYPEOF_REGISTER_TEMPLATE(boost::interthreads::unique_future, 1) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::interthreads::shared_future, 1) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::interthreads::promise, 1) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::interthreads::packaged_task, 1) #endif ====================
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
If we register unique_future on the Boost.Typeof library, we are able to write
BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread));
which is much simpler.
Next follows the contents of the file. Could this file be added to the Boost.Future librarie?
I'd have thought so. I'm not keen on depending on boost.typeof, but it would be fine as a separate header. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 20, 2009 3:39 PM Subject: Re: [boost] Futures Review - typeof registering
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
If we register unique_future on the Boost.Typeof library, we are able to write
BOOST_AUTO(handles, bith::fork_all(ae, simple_thread, simple_thread));
which is much simpler.
Next follows the contents of the file. Could this file be added to the Boost.Future librarie?
I'd have thought so. I'm not keen on depending on boost.typeof, but it would be fine as a separate header.
Great, Vicente
Hi Anthony, Please, could you give us which is the Concept for the wait_for_any parameter template function? It is not clear from the documentation which are the functions must be provided by the Models. Thanks, Vicente -- View this message in context: http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tp2130... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet Escriba <vicente.botet@wanadoo.fr> writes:
Please, could you give us which is the Concept for the wait_for_any parameter template function? It is not clear from the documentation which are the functions must be provided by the Models.
With the library as it stands, wait_for_any works with any specializations of unique_future or shared_future, but only those --- it is inherently tied to their implementation. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, January 14, 2009 3:43 PM Subject: Re: [boost] Futures Review - wait_for_any Concept parameters
Vicente Botet Escriba <vicente.botet@wanadoo.fr> writes:
Please, could you give us which is the Concept for the wait_for_any parameter template function? It is not clear from the documentation which are the functions must be provided by the Models.
With the library as it stands, wait_for_any works with any specializations of unique_future or shared_future, but only those --- it is inherently tied to their implementation.
Oh, I see. I've missed that on the documentation which is clearly stated on the preconditions. If this function works only for unique/shared future, its name is too generic to be placed at the boost namespace. Do you plan to include it in a specific futures namespace? Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, January 14, 2009 3:43 PM Subject: Re: [boost] Futures Review - wait_for_any Concept parameters
Vicente Botet Escriba <vicente.botet@wanadoo.fr> writes:
Please, could you give us which is the Concept for the wait_for_any parameter template function? It is not clear from the documentation which are the functions must be provided by the Models.
With the library as it stands, wait_for_any works with any specializations of unique_future or shared_future, but only those --- it is inherently tied to their implementation.
Oh, I see. I've missed that on the documentation which is clearly stated on the preconditions.
If this function works only for unique/shared future, its name is too generic to be placed at the boost namespace. Do you plan to include it in a specific futures namespace?
It could be moved inside a namespace. I'm not really bothered. Alternatively, if it could be extended for other types then that would work too. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi, Currently the wait callback parameter is either a promise or packaged_task template<typename F> void set_wait_callback(F f); prom.set_wait_callback(f); // will call f(&prom) task.set_wait_callback(f); // will call f(&task) I would like to have a wait callback with a user specific parameter. template<typename F,typename U> void set_wait_callback(F f,U* u); // will call f(u) prom.set_wait_callback(f, x); // will call f(x) The use case is a class that contains a promise and wants to provide a set_wait_callback. Which parameter will have the wait calback? A promise. But the user is not aware that my class has promise, and he will surely want to have as parameter a pointer to my class. So the simpler is to provide a user specific parameter that is defaulted to instance providing the wait_callback setting. Of course my class can wrap the user function and the class instance template <typename R> class X { template <typename F> static void wait_callback_wrapper(promise<R>* p, F f, X*x) { f(x); } template<typename F> void set_wait_callback(F f) { prom_.set_wait_callback(bind(wait_callback_wrapper, _1, f, this)); } }; But this implies much more resources, two binds instead of one. Could this be added without to much trouble? Thanks, Vicente
----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Thursday, January 15, 2009 6:47 PM Subject: Re: [boost] Futures - wait callback with a user specific parameter.
Hi,
Currently the wait callback parameter is either a promise or packaged_task template<typename F> void set_wait_callback(F f);
prom.set_wait_callback(f); // will call f(&prom) task.set_wait_callback(f); // will call f(&task)
I would like to have a wait callback with a user specific parameter. template<typename F,typename U> void set_wait_callback(F f,U* u); // will call f(u)
prom.set_wait_callback(f, x); // will call f(x)
The use case is a class that contains a promise and wants to provide a set_wait_callback. Which parameter will have the wait calback? A promise. But the user is not aware that my class has promise, and he will surely want to have as parameter a pointer to my class. So the simpler is to provide a user specific parameter that is defaulted to instance providing the wait_callback setting.
Of course my class can wrap the user function and the class instance
template <typename R> class X { template <typename F> static void wait_callback_wrapper(promise<R>* p, F f, X*x) { f(x); }
template<typename F> void set_wait_callback(F f) { prom_.set_wait_callback(bind(wait_callback_wrapper, _1, f, this)); } };
But this implies much more resources, two binds instead of one. Could this be added without to much trouble?
Anthony, I've find this on one your posts:
At the moment, I've specified the callbacks as taking a non-const reference to the promise or packaged_task for which they are set, but I'm open to just making them be any callable function, and leaving it up to the user to call bind() to do that.
Anthony, I think that just a callable function will be the best option. Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
From: "vicente.botet" <vicente.botet@wanadoo.fr>
Currently the wait callback parameter is either a promise or packaged_task template<typename F> void set_wait_callback(F f);
prom.set_wait_callback(f); // will call f(&prom) task.set_wait_callback(f); // will call f(&task)
I would like to have a wait callback with a user specific parameter. template<typename F,typename U> void set_wait_callback(F f,U* u); // will call f(u)
prom.set_wait_callback(f, x); // will call f(x)
The use case is a class that contains a promise and wants to provide a set_wait_callback. Which parameter will have the wait calback? A promise. But the user is not aware that my class has promise, and he will surely want to have as parameter a pointer to my class. So the simpler is to provide a user specific parameter that is defaulted to instance providing the wait_callback setting.
Of course my class can wrap the user function and the class instance
template <typename R> class X { template <typename F> static void wait_callback_wrapper(promise<R>* p, F f, X*x) { f(x); }
template<typename F> void set_wait_callback(F f) { prom_.set_wait_callback(bind(wait_callback_wrapper, _1, f, this)); } };
But this implies much more resources, two binds instead of one. Could this be added without to much trouble?
It could, but....
Anthony, I've find this on one your posts:
At the moment, I've specified the callbacks as taking a non-const reference to the promise or packaged_task for which they are set, but I'm open to just making them be any callable function, and leaving it up to the user to call bind() to do that.
Anthony, I think that just a callable function will be the best option.
.... I think this is the best option. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi, The one or many callbacks setting subject comeback regularly. I would like the Boost.Future future library supports callbacks but not always, i.e. I would like a design that has 0-callbacks (current standard recomendation). On top of it we must be able to implement 1-callbacks, and on top of it implement n-callbacks (or signals). This should be applied either to callbacks on wait (Anthony) as callback on setting (Braddock). Is it possible to achieve this design? If this is not possible IMHO the standard C++0x futures is incomplete, and should be modified. If it is possible, is there any deep reason to not provide it? Thanks, Vicente
Hi, there was a long discusion about the complexity of wait_for_any some mounts ago. If I understood well the probleme was in the future_waiter::wait unsigned wait() { all_futures_lock lk(futures); for(;;) { for(unsigned i=0;i<futures.size();++i) // O(N) { if(futures[i].future->done) { return futures[i].index; } } cv.wait(lk); } } What we need is a synchonization structure that returns a user specific data (in this case the index). So we can replace by unsigned wait() { all_futures_lock lk(futures); return cv_with_value.wait(lk); } We need to pass to the register_external_waiter the specific data, in this case the index template<typename F> void add(F& f) { if(f.future) { futures.push_back(registered_waiter(f.future, f.future->register_external_waiter(cv_with_value,future_count),future_count)); } ++future_count; } So the list of waiters is now typedef std::list<std::pair<condition_variable_any_with_value<unsigned>*, unsigned> > waiter_list; waiter_list::iterator register_external_waiter( condition_variable_any_with_value<unsigned>& cv_with_value, unsigned indx) { boost::unique_lock<boost::mutex> lock(mutex); do_callback(lock); return external_waiters.insert(external_waiters.end(),std::make_pair(&cv, indx)); } The notification to the waiters will no use the new notify_all interface passing as parameter the index of the future relative to the condition_variable. void mark_finished_internal() { done=true; waiters.notify_all(); for(waiter_list::const_iterator it=external_waiters.begin(), end=external_waiters.end();it!=end;++it) { (it->first)->notify_all(it->second); } } The interface of the condition_variable_any_with_value is the same as condition_variable_any but template <typename T> class condition_variable_any_with_value { // add a get function T get(); // gets the value stored when notify called // change the interface for the notify functions bool notify_one(T val); bool notify_all(T val); }; What do you think?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
there was a long discusion about the complexity of wait_for_any some mounts ago. If I understood well the probleme was in the future_waiter::wait
unsigned wait() { all_futures_lock lk(futures); for(;;) { for(unsigned i=0;i<futures.size();++i) // O(N) { if(futures[i].future->done) { return futures[i].index; } } cv.wait(lk); } }
Yes.
What we need is a synchonization structure that returns a user specific data (in this case the index). So we can replace by
unsigned wait() { all_futures_lock lk(futures); return cv_with_value.wait(lk); }
I'm not sure. I think we're better off with a simple mutex/value/cond-var triplet in the waiter. We then don't need the "all_futures_lock". unsigned wait() { boost::unique_lock<boost::mutex> lk(mut); while(ready_future_index<0) { cv.wait(lk); } return ready_future_index; }
We need to pass to the register_external_waiter the specific data, in this case the index
and the mutex => better off as a struct of some kind. struct ready_future_value { boost::mutex mut; int ready_future_index; boost::condition_variable cv; void notify_ready(unsigned index) { boost::lock_guard<boost::mutex> lk(mut); if(ready_future_index<0) { ready_future_index=index; cv.notify_all(); } } } ready_value;
template<typename F> void add(F& f) { if(f.future) { futures.push_back(registered_waiter(f.future, // f.future->register_external_waiter(cv,future_count,mut),future_count));
f.future->register_external_waiter(&ready_value,future_count),future_count));
} ++future_count; }
So the list of waiters is now
// typedef std::list<std::pair<condition_variable_any_with_value<unsigned>*,
typedef std::list<std::pair<ready_future_value*,
unsigned> > waiter_list; waiter_list::iterator register_external_waiter( // condition_variable_any_with_value<unsigned>& cv_with_value,
ready_future_value& ready_value,
unsigned indx) { boost::unique_lock<boost::mutex> lock(mutex); do_callback(lock); return external_waiters.insert(external_waiters.end(),std::make_pair(&cv, indx)); }
The notification to the waiters will no use the new notify_all interface passing as parameter the index of the future relative to the condition_variable.
void mark_finished_internal() { done=true; waiters.notify_all(); for(waiter_list::const_iterator it=external_waiters.begin(), end=external_waiters.end();it!=end;++it) {
(it->first)->notify_ready(it->second);
} }
It turns out that my ready_future_value struct isn't too far from your cv_with_value, so I like the idea, but not the name. (I don't like ready_future_value either for that matter). Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 20, 2009 3:01 PM Subject: Re: [boost] Futures Review - wait_for_any complexity
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
What we need is a synchonization structure that returns a user specific data (in this case the index). So we can replace by
unsigned wait() { all_futures_lock lk(futures); return cv_with_value.wait(lk); }
I'm not sure. I think we're better off with a simple mutex/value/cond-var triplet in the waiter. We then don't need the "all_futures_lock".
unsigned wait() { boost::unique_lock<boost::mutex> lk(mut); while(ready_future_index<0) { cv.wait(lk); } return ready_future_index; }
Great.
We need to pass to the register_external_waiter the specific data, in this case the index
and the mutex => better off as a struct of some kind.
struct ready_future_value { boost::mutex mut; int ready_future_index; boost::condition_variable cv;
void notify_ready(unsigned index) { boost::lock_guard<boost::mutex> lk(mut); if(ready_future_index<0) { ready_future_index=index; cv.notify_all(); } } } ready_value;
Yes you are right, the mutex is also needed. It was supposed to be encapsulated on my proposal.
template<typename F> void add(F& f) { if(f.future) { futures.push_back(registered_waiter(f.future, // f.future->register_external_waiter(cv,future_count,mut),future_count));
f.future->register_external_waiter(&ready_value,future_count),future_count));
} ++future_count; }
So the list of waiters is now
// typedef std::list<std::pair<condition_variable_any_with_value<unsigned>*,
typedef std::list<std::pair<ready_future_value*,
unsigned> > waiter_list; waiter_list::iterator register_external_waiter( // condition_variable_any_with_value<unsigned>& cv_with_value,
ready_future_value& ready_value,
unsigned indx) { boost::unique_lock<boost::mutex> lock(mutex); do_callback(lock); return external_waiters.insert(external_waiters.end(),std::make_pair(&cv, indx)); }
The notification to the waiters will no use the new notify_all interface passing as parameter the index of the future relative to the condition_variable.
void mark_finished_internal() { done=true; waiters.notify_all(); for(waiter_list::const_iterator it=external_waiters.begin(), end=external_waiters.end();it!=end;++it) {
(it->first)->notify_ready(it->second);
} }
It turns out that my ready_future_value struct isn't too far from your cv_with_value, so I like the idea, but not the name. (I don't like ready_future_value either for that matter).
Yes, it seems to be the same. I have no better proposal for the name now. Hoping this will improve the performances of wait_for_any, Vicente
Hi, The functions wait_for_all and wait_for_any seams quite generic and could be applied to other asynchronous completion tokens (ACT), as for example the tp::task from Boost.ThreadPool. In order to do that we need to be able to partialy specialize these functions or use traits: Let me start with a partial specialization proposal template<typename F1,typename F2,typename F3> unsigned wait_for_any(F1& f1,F2& f2,F3& f3) { return partial_specialization_workaround::wait_for_any::apply(f1,f2, f3); } namespace partial_specialization_workaround { template<typename Types> struct wait_for_any; template<typename F1,typename F2,typename F3> struct wait_for_any<vector3<F1,F2,F3> > { unsigned apply(F1& f1,F2& f2,F3& f3) { detail::future_waiter waiter; waiter.add(f1); waiter.add(f2); waiter.add(f3); return waiter.wait(); } }; } With traits thing simpler . The traits class will have a function that gets a unique/shared_future from the ACT. template<typename F1,typename F2> typename boost::enable_if<is_future_type<F1>,unsigned>::type wait_for_any(F1& f1,F2& f2) { detail::future_waiter waiter; waiter.add(traits::get_future(f1)); waiter.add(traits::get_future(f2)); return waiter.wait(); } The default get_future traits will return its parameter template <typename ACT> struct traits { ACT& get_future(ACT& act) { return act; } }; What do you think? Vicente
Hi, Could the wait_for_ functions be overloaded for fusion sequences, e.g. fusion::vector<shared_future<int>, shared_future<string> > seq; unsigned i = wait_for_any(seq); I have checkd the followig code and it works for me. struct waiter_add { waiter_add(boost::detail::future_waiter& waiter) : waiter_(waiter) {} boost::detail::future_waiter& waiter_; template<typename ACT> void operator()(ACT& act) const { waiter_.add(act); } }; template<typename FusionSequence> unsigned wait_for_any(FusionSequence& seq) { boost::detail::future_waiter waiter; boost::fusion::for_each(seq, waiter_add(waiter)); return waiter.wait(); } Thanks, Vicente
Hi, I have add the fork_after function to Boost.InterThreads. The prototype allows to execute asynchronously N functions and execute asynchronously a function that depends on the completion of N functions. bith::shared_launcher ae; BOOST_AUTO(actT, bith::fork_all(ae, fct1, fct2)); BOOST_AUTO(act,bith::fork_after(ae, fct3, actT)); act.wait(); bith::shared_launcher is an asynchronous executor (AE) that executes asynchronously a function on a new thread. bith::fork_all request the AE to execute asynchronously each function. It returns a fusion tuple of the asynchronous completion token (ACT) associated the the ae. bith::fork_after request the AE to execute a function asynchronously once each one of ACTs in the dependency tuple parameter are ready. It is similar to the async_with_dependencies proposed Peter Dimov. I have used for that Boost.Future (Anthony proposal). Is there any interest in this kind of feautres? Best, Vicente
Hi, what is happening with the Boost.Future review. The authors do not respond too much to the posts. There iare not too much reviews neither posts. There was a review sent the 6th - no comments. Another the 7th,the same I have posted 6 post for discusion and no answerr since the 15th. We are amready the 18th, the review finish the 20h and Tom, the review manager is not calling for reviews, neither pesting on the authors to answer the questions included in the posts. We don't have any sign of Braddock since a lot time, is he hill? Am I missing something? Has the review been canceled? Tom please could you clarify these questions? Thanks, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
what is happening with the Boost.Future review. The authors do not respond too much to the posts. There iare not too much reviews neither posts. There was a review sent the 6th - no comments. Another the 7th,the same I have posted 6 post for discusion and no answerr since the 15th.
Sorry for the lack of response; I've not been reading the boost list for a few days.
Am I missing something? Has the review been canceled?
Not to my knowledge. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Hi, here is my review. * What is your evaluation of the design? Both libraries have a good design. The fact that the porposal of Anthony is closer to the C++0x proposal let me think that we should base the Boost.Library on it and see how to add the other features. For the exception propagation mechanism both libraries must use Boost.Exception (as is already the case of Anthony version). The library should use the forthcomming Boost.Move library to emulate the move semantics. The library should use the forthcomming Boost.Chrono library for time and duration. With wait_for_all and wait_for_any we don't need the Braddock completion callback setting, even if it could be less efficient, it is safer. I have however, some points that seems to me necessary for acceptance: ++ C++0x adaptations: ++ adapt the exceptions hierarchy to a single exception. ++ Change the names of timed_wait to follow the stndard wait_until and wait_for. + Add a typeof registerig (See http://www.nabble.com/forum/ViewPost.jtp?post=21388525&framed=y) ++ Allows partial specialization of wait_for_any (see http://www.nabble.com/forum/ViewPost.jtp?post=21504868&framed=y) + Use a get_future traits on the default implementation of wait_for_any and wait_for_all ++ Futures are asynchronous completion tokens. I would like the library defines this concept. Functions like wait_for_any, wait_for_all should work with every model of an ACT. If the implementation could not provide this, these functions must be moved to a specific future namespace. + The one or many wait callbacks setting subject come back regularly. I would like the Boost.Future future library supports wait callbacks but not always, i.e. I would like a design that don't supprots callbacks (current standard recomendation). On top of it we must be able to implement 1-callbacks, and on top of it implement n-callbacks (or signals). + Add wait_for_ functions be overloaded for fusion sequences, e.g. fusion::vector<shared_future<int>, shared_future<string> > seq; unsigned i = wait_for_any(seq); See http://www.nabble.com/forum/ViewPost.jtp?post=21517138&framed=y + Add a typedef or a trait class to get the value type of a future - No implicit conversion must be provided + It will be great to have a DSEL defining the operators && and || as proposed by Hartmut Kaiser and others. * What is your evaluation of the implementation? Both implementations seem to be of good quality. Only one deep remark: ++ take in account my proposal on wait_for_any complexity (See http://www.nabble.com/forum/ViewPost.jtp?post=21494006&framed=y) and some minor ones (see http://www.nabble.com/forum/ViewPost.jtp?post=21320253&framed=y) * What is your evaluation of the documentation? I have spent quite a lot of time reviewing them, and both seem fine but William's should add a more extensive tutorial and examples that show to the user how the most useful uses cases of the library can be done without dificulty. In general it will be good to see how the specific features of the Braddock proposal are managed by the standard proposal. + A Reference to the ThreadPool library documentation could see how complex a thread_pool can be . + Add an example of use with containers of futures and why not with fusion sequences. + Add a schedule with dependencies example (wait_for_any,wait_for_all). + Add an example of scheduling a function taking futures as parameters. I think that this documentation should be added before complete acceptance. * What is your evaluation of the potential usefulness of the library? Extremely useful. This will be the base for a more high level concurrency libraries as ThreadPool. * Did you try to use the library? With what compiler? Did you have any problems? I have used the Anthony version, I used gcc 3.4.4 with cygwin and I have found just the problem with the move of packaged_task. My library interthreads use the Anthony Future library for the asynchronous execution framework. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've spent a lot of hours. * Are you knowledgeable about the problem domain? Quite. I've used the ACE futures on production code since more that 5 years. I have proposed changes on the wait_for_any function improving the complexity. I have implementated an asynchronous execution framework recently. * Do you think the library should be accepted as a Boost library? The fact that Olivier has adapted its ThreadPool library without not too much problems and that I was able to use the futures as ACT in my ae-act framework let me think that the interface is quite stable. My fork_after function is a prove of concept that we can schedule executions once a number of ACT are completed (I have no performance measures). My vote will be Yes for the Anthony proposal once we find consensus on my suggestions and the documentation is completed. So only provisional acceptance. Vicente
Hi, The function get is defined in the documentation with following prototypes R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get(); But when the move semantic is emulated this is just translated as move_dest_type get() with move_dest_type defined depending on the future template parameter as follows typedef typename detail::future_traits<R>::move_dest_type move_dest_type; template<typename T> struct future_traits { #ifdef BOOST_HAS_RVALUE_REFS typedef T const& source_reference_type; struct dummy; typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type; #else typedef T& source_reference_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T>::type move_dest_type; #endif }; Generic libraries using the futures needs to get the type returned by get. What do you think about making the move_dest_type public at least when BOOST_HAS_RVALUE_REFS is not defined? Another option would be to make public the future_traits class. Best, Vicente
Hello, I first posted this two weeks ago for the review, allow me to repost just in case it went unnoticed: ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Saturday, January 24, 2009 12:38 AM Subject: Re: [boost] Futures Review - can move_dest_type be public?
Hi,
The function get is defined in the documentation with following prototypes
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();
But when the move semantic is emulated this is just translated as
move_dest_type get()
with move_dest_type defined depending on the future template parameter as follows
typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
template<typename T> struct future_traits { #ifdef BOOST_HAS_RVALUE_REFS typedef T const& source_reference_type; struct dummy; typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type; #else typedef T& source_reference_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T>::type move_dest_type; #endif
};
Generic libraries using the futures needs to get the type returned by get. What do you think about making the move_dest_type public at least when BOOST_HAS_RVALUE_REFS is not defined? Another option would be to make public the future_traits class.
Best, Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Hi,
The function get is defined in the documentation with following prototypes
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();
But when the move semantic is emulated this is just translated as
move_dest_type get()
with move_dest_type defined depending on the future template parameter as follows
typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
template<typename T> struct future_traits { #ifdef BOOST_HAS_RVALUE_REFS typedef T const& source_reference_type; struct dummy; typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type; #else typedef T& source_reference_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T>::type move_dest_type; #endif
};
Generic libraries using the futures needs to get the type returned by get. What do you think about making the move_dest_type public at least when BOOST_HAS_RVALUE_REFS is not defined? Another option would be to make public the future_traits class.
That's an interesting idea. I can see the benefit of being able to know the type of unique_future<T>::get() without having to use decltype/BOOST_TYPEOF. Maybe a unique_future<T>::get_result_type typedef would be most appropriate. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, February 10, 2009 6:22 PM Subject: Re: [boost] [repost] Futures Review - can move_dest_type be public?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Hi,
The function get is defined in the documentation with following prototypes
R&& unique_future::get(); R& unique_future<R&>::get(); void unique_future<void>::get();
But when the move semantic is emulated this is just translated as
move_dest_type get()
with move_dest_type defined depending on the future template parameter as follows
typedef typename detail::future_traits<R>::move_dest_type move_dest_type;
template<typename T> struct future_traits { #ifdef BOOST_HAS_RVALUE_REFS typedef T const& source_reference_type; struct dummy; typedef typename boost::mpl::if_<boost::is_fundamental<T>,dummy&,T&&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_fundamental<T>,T,T&&>::type move_dest_type; #else typedef T& source_reference_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T const&>::type rvalue_source_type; typedef typename boost::mpl::if_<boost::is_convertible<T&,boost::detail::thread_move_t<T> >,boost::detail::thread_move_t<T>,T>::type move_dest_type; #endif
};
Generic libraries using the futures needs to get the type returned by get. What do you think about making the move_dest_type public at least when BOOST_HAS_RVALUE_REFS is not defined? Another option would be to make public the future_traits class.
That's an interesting idea. I can see the benefit of being able to know the type of unique_future<T>::get() without having to use decltype/BOOST_TYPEOF.
Maybe a unique_future<T>::get_result_type typedef would be most appropriate.
This will be Ok to my needs. Thanks, Vicente
Hi, In C++0x const R& shared_future::get() const; R& shared_future<R&>::get() const; void shared_future<void>::get() const; In the documentation We found in the synopsis class R get(); in the Member function get() const R& get(); in the description Effects:If *this is associated with an asynchronous result, waits until the result is ready as-if by a call to jss::shared_future<R>::wait(), and returns a const reference to the result. Returns:If the result type R is a reference, returns the stored reference. If R is void, there is no return value. Otherwise, returns a const reference to the value stored in the asynchronous result. In the code we have R get() There is a lot of incoherences. Which is the correct one? Vicente
Hi, Currently when we set_wait_callback on a packaged_task, the packaged_task is given by reference to the callback function. This means that the packaged_task can not be moved. As packaged_task is not CopyConstructible this limits quite a lot its use together with set_wait_callback. We need to pass it always by reference as functions parameters and can't be returned by a function. I have tried to make a lazy_call function similar to spawn_task in the defined in N2709 template<typename F> std::unique_future<typename std::result_of<F()>::type> spawn_task(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type()> task(std::move(f)); std::unique_future<result_type> res(task.get_future()); std::thread(std::move(task)); return res; } Here it is template<typename F> std::unique_future<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) std::unique_future<result_type> res(task.get_future()); return res; } but I need to return the packaged_task instead of the future because its lifetime must be longuer than the future->get() call. So I've tried to move the packaged_task which don't work either because the promise is broken template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) return task; } Is there a way to implement this kind of function, other than wrapping the packaged_task on a CopyConstructible class? template<typename F> shared_ptr<std::packaged_task<typename std::result_of<F()>::type>> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; shared_ptr<std::packaged_task<result_type>> task_ptr(new std::packaged_task<result_type()> (std::move(f))); task_ptr->set_wait_callback(invoke_lazy_task<result_type>()) return task_ptr; } What is the rationale for making packaged_task movable only? Why should not be CopyConstructible? Thanks, Vicente ========== template <typename T> struct invoke_lazy_task { typedef void result_type; void operator()(packaged_task<T>& task) { try { task(); } catch(task_already_started&) {} } };
Hello, I first posted this two weeks ago, allow me to repost just in case it went unnoticed: Best, Vicente ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Monday, January 26, 2009 11:00 PM Subject: Re: [boost] Futures Review - Should packaged_task beCopyConstructible?
Hi,
Currently when we set_wait_callback on a packaged_task, the packaged_task is given by reference to the callback function. This means that the packaged_task can not be moved.
As packaged_task is not CopyConstructible this limits quite a lot its use together with set_wait_callback. We need to pass it always by reference as functions parameters and can't be returned by a function.
I have tried to make a lazy_call function similar to spawn_task in the defined in N2709
template<typename F> std::unique_future<typename std::result_of<F()>::type> spawn_task(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type()> task(std::move(f)); std::unique_future<result_type> res(task.get_future()); std::thread(std::move(task)); return res; }
Here it is
template<typename F> std::unique_future<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) std::unique_future<result_type> res(task.get_future()); return res; }
but I need to return the packaged_task instead of the future because its lifetime must be longuer than the future->get() call. So I've tried to move the packaged_task which don't work either because the promise is broken
template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) return task; }
Is there a way to implement this kind of function, other than wrapping the packaged_task on a CopyConstructible class?
template<typename F> shared_ptr<std::packaged_task<typename std::result_of<F()>::type>> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; shared_ptr<std::packaged_task<result_type>> task_ptr(new std::packaged_task<result_type()> (std::move(f))); task_ptr->set_wait_callback(invoke_lazy_task<result_type>()) return task_ptr; }
What is the rationale for making packaged_task movable only? Why should not be CopyConstructible?
Thanks, Vicente
========== template <typename T> struct invoke_lazy_task { typedef void result_type; void operator()(packaged_task<T>& task) { try { task(); } catch(task_already_started&) {} } };
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Currently when we set_wait_callback on a packaged_task, the packaged_task is given by reference to the callback function. This means that the packaged_task can not be moved.
As packaged_task is not CopyConstructible this limits quite a lot its use together with set_wait_callback. We need to pass it always by reference as functions parameters and can't be returned by a function.
I have tried to make a lazy_call function similar to spawn_task in the defined in N2709
template<typename F> std::unique_future<typename std::result_of<F()>::type> spawn_task(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type()> task(std::move(f)); std::unique_future<result_type> res(task.get_future()); std::thread(std::move(task)); return res; }
Here it is
template<typename F> std::unique_future<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) std::unique_future<result_type> res(task.get_future()); return res; }
but I need to return the packaged_task instead of the future because its lifetime must be longuer than the future->get() call. So I've tried to move the packaged_task which don't work either because the promise is broken
template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) return task; }
Why does this not work? Is it that the callback is broken (it gets passed the wrong task?) If so, that's the part that needs fixing, rather than the copyability of packaged_task.
What is the rationale for making packaged_task movable only? Why should not be CopyConstructible?
If packaged_task was copyable, people would copy it and expect the copy to be associated with the futures they obtained from the original. Not necessarily deliberately, but by mistake (e.g. copying into a vector rather than moving). This is not the case. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, February 10, 2009 6:28 PM Subject: Re: [boost] Futures Review - Should packaged_taskbeCopyConstructible?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
So I've
tried to move the packaged_task which don't work either because the promise is broken
template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f) { typedef typename std::result_of<F()>::type result_type; std::packaged_task<result_type> task(std::move(f)); task.set_wait_callback(invoke_lazy_task<result_type>()) return task; }
Why does this not work? Is it that the callback is broken (it gets passed the wrong task?) If so, that's the part that needs fixing, rather than the copyability of packaged_task.
Sorry i was not clear. The problem is that the reference to the task std::packaged_task<result_type> task(std::move(f)); has been stored in the set_wait_callback. But this address is no more valable when the function returns, so when the user gets the future and call to get, the callback uses a bad address. Hoping it is clear now.
What is the rationale for making packaged_task movable only? Why should not be CopyConstructible?
If packaged_task was copyable, people would copy it and expect the copy to be associated with the futures they obtained from the original. Not necessarily deliberately, but by mistake (e.g. copying into a vector rather than moving). This is not the case.
Ok, I see. Anyway, I think that examples like template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f); should be included in the library, at least as an example. Best, Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Sorry i was not clear. The problem is that the reference to the task
std::packaged_task<result_type> task(std::move(f));
has been stored in the set_wait_callback. But this address is no more valable when the function returns, so when the user gets the future and call to get, the callback uses a bad address. Hoping it is clear now.
Yes, it's clear. That's a design issue with set_wait_callback.
Ok, I see. Anyway, I think that examples like template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f);
should be included in the library, at least as an example.
That's a good idea. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, February 11, 2009 9:31 AM Subject: Re: [boost] Futures Review - Shouldpackaged_taskbeCopyConstructible?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Sorry i was not clear. The problem is that the reference to the task
std::packaged_task<result_type> task(std::move(f));
has been stored in the set_wait_callback. But this address is no more valable when the function returns, so when the user gets the future and call to get, the callback uses a bad address. Hoping it is clear now.
Yes, it's clear. That's a design issue with set_wait_callback.
Ok, I see. Anyway, I think that examples like template<typename F> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f);
should be included in the library, at least as an example.
That's a good idea.
Have you an idea how to solve the design issue to implement lazy_call? In http://www.nabble.com/Futures-Review-Starts-Today---January-5%2C-2009-tt2130..., I requested the differences between a lazy future and a function pointer. Please could you answer to this post? Best, Vicente
Hi, are lazy futures a kind of function pointer? How is the example from the documentation int calculate_the_answer_to_life_the_universe_and_everything(){ return 42; } void invoke_lazy_task(jss::packaged_task<int>& task){ try { task(); } catch(jss::task_already_started&) {} } int main() { jss::packaged_task<int> task(calculate_the_answer_to_life_the_universe_and_everything); task.set_wait_callback(invoke_lazy_task); jss::unique_future<int> f(task.get_future()); assert(f.get()==42); } differ from int main(){ function<int()> task(calculate_the_answer_to_life_the_universe_and_everything); assert(task()==42); } What I'm missing? Could you show other use cases for the set_wait_callback function? Thanks, Vicente _____________________ Vicente Juan Botet Escribá
Hi, ----- Original Message ----- From: "Tom Brinkman" <reportbase@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, January 06, 2009 2:25 AM Subject: [boost] Futures Review Starts Today - January 5, 2009
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review? There was not too much reviews, neither responses from the authors, ... What happened? Nevertheless, I'm sure that this library is essential to the construction of high level concurrent libraries. Tom, it will be good if you can close this extraneous review. Vicente
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Good question. It was supposed to be over by now, but there's been no statement from Tom.
There was not too much reviews, neither responses from the authors, ... What happened?
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
Nevertheless, I'm sure that this library is essential to the construction of high level concurrent libraries.
If you want to include my code (or something derived from it) in your interthreads library, or Oliver wants to include it with his threadpool submission, that's fine by me. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Good question. It was supposed to be over by now, but there's been no statement from Tom.
There was not too much reviews, neither responses from the authors, ... What happened?
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
From my point of view, I was interested, but I found the idea of reviewing two libraries at once to be simply overwhelming.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams <dave@boostpro.com> writes:
on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
From my point of view, I was interested, but I found the idea of reviewing two libraries at once to be simply overwhelming.
Given that we do have two proposed libraries, have you any suggestions on how to make the review process less overwhelming? Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On 10 Feb 2009, at 17:08, David Abrahams wrote:
on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Good question. It was supposed to be over by now, but there's been no statement from Tom.
There was not too much reviews, neither responses from the authors, ... What happened?
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
From my point of view, I was interested, but I found the idea of reviewing two libraries at once to be simply overwhelming.
I want to back this up - I am very interested in futures, but I decided not to get involved in this review for two reasons. 1) Medium to long term, I want to be able to use, or build on, the standard futures, so I would like a library which strictly extends that. 2) I don't feel sufficently qualified to choose between two different libraries, and all the trade-offs involved, knowing (assuming?) that at least one of the libraries would have to be rejected. I would be much happier if the two library authors could come together and merge their work. Chris
On Tue, Feb 10, 2009 at 6:51 PM, Christopher Jefferson <chris@bubblescope.net> wrote:
On 10 Feb 2009, at 17:08, David Abrahams wrote:
on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
From my point of view, I was interested, but I found the idea of reviewing two libraries at once to be simply overwhelming.
I want to back this up - I am very interested in futures, but I decided not to get involved in this review for two reasons.
1) Medium to long term, I want to be able to use, or build on, the standard futures, so I would like a library which strictly extends that. 2) I don't feel sufficently qualified to choose between two different libraries, and all the trade-offs involved, knowing (assuming?) that at least one of the libraries would have to be rejected.
Seconded. I'm quite interested in a futures library, but I didn't have the time nor the the ability to try to find out which library really were the be selected.
I would be much happier if the two library authors could come together and merge their work.
Yes please :) -- gpd
----- Original Message ----- From: "Christopher Jefferson" <chris@bubblescope.net> To: <boost@lists.boost.org> Sent: Tuesday, February 10, 2009 6:51 PM Subject: Re: [boost] Futures Review -- Where we are with the Futures review?
On 10 Feb 2009, at 17:08, David Abrahams wrote:
on Tue Feb 10 2009, Anthony Williams <anthony.ajw-AT-gmail.com> wrote:
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Good question. It was supposed to be over by now, but there's been no statement from Tom.
There was not too much reviews, neither responses from the authors, ... What happened?
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
From my point of view, I was interested, but I found the idea of reviewing two libraries at once to be simply overwhelming.
I want to back this up - I am very interested in futures, but I decided not to get involved in this review for two reasons.
IMO, this is a shame.
1) Medium to long term, I want to be able to use, or build on, the standard futures, so I would like a library which strictly extends that.
I agree. So we needed, starting from the current C++0x proposa, to see which other features were absolutly needed. The features don't needing any modification on the standard will pose no problem. But those features needing to be implemented intrusively will be asignal of something missing on the standard.
2) I don't feel sufficently qualified to choose between two different libraries, and all the trade-offs involved, knowing (assuming?) that at least one of the libraries would have to be rejected.
Both authors had state that they will work together to get the Boost.Future. So no need to choose, just select the features.
I would be much happier if the two library authors could come together and merge their work.
I realy thoght this will happens this way. Vicente
----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, February 10, 2009 5:58 PM Subject: Re: [boost] Futures Review -- Where we are with the Futures review?
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Futures Review Starts Today - January 5, 2009
Where we are with the Futures review?
Good question. It was supposed to be over by now, but there's been no statement from Tom.
There was not too much reviews, neither responses from the authors, ... What happened?
Sorry for not taking the time to respond to all your comments. They are much appreciated. Maybe the lack of reviews indicates a lack of interest from the Boost community? That's a shame, if so.
Could you try to respond now. I'll realy appreciate.
Nevertheless, I'm sure that this library is essential to the construction of high level concurrent libraries.
If you want to include my code (or something derived from it) in your interthreads library, or Oliver wants to include it with his threadpool submission, that's fine by me.
Thanks for the offert. But it will be realy a shame to don't have a Future library in Boost. Even if Olivier or me included it on his library futures mast be first class in Boost. Regards, Vicente
participants (13)
-
Anthony Williams -
Christopher Jefferson -
David Abrahams -
Emil Dotchevski -
Giovanni Piero Deretta -
Johan Torp -
Oliver Kowalke -
Oliver Seiler -
Phil Endecott -
Steven Watanabe -
Tom Brinkman -
Vicente Botet Escriba -
vicente.botet