On Monday 19 January 2009 13:19, Johan Torp wrote:
Vicente Botet Escriba wrote:
I would not be surprised if requiring a third thread for future composition would render it useless for many of Gaskill's use cases, libpoet and asio - which means most of the identified use cases. But I'm far from sure.
Could you or someone develop these needs.
The authors of asio, libpoet and Gaskill are best suited to answer if Anthony's proposal would be useful to them.
Unfortunately, I haven't had time to follow the future review threads in detail, or any changes that may have been made to the submitted library since I last looked at them many months ago. I can only summarize some things about the future implementation in libpoet in the hope it will be helpful in some way. As far as composing futures, the poet::future_combining_barrier supports obtaining a new future whose value is obtained by applying an arbitrary "combiner" functor to the values from a group of input futures. The combiner is always executed in a future-waiting thread, not the promise-fulfilling thread, or a third thread. The implementation relies on internal signals being emitted immediately when a promise is fulfilled, as well as internal event queues associated with futures. I described it a little in this post: http://lists.boost.org/Archives/boost/2008/06/138422.php With respect to an O(1) future wait_for_any, I added poet::future_selector, which is like a future queue which reorders based on the order that the futures pushed into the queue become ready. I was able to use them to reimplement my schedulers for active objects, without the scheduler using "future is ready" callbacks directly. To be more clear about my use case: I have a thread which executes method requests, and each method request has a group of futures associated with it. The thread's scheduler has a queue of method requests and it selects a method request to run when all the method request's futures are ready.