Anthony Williams-3 wrote:
I have read your comments. My primary reason for including this came from thread pools: if you know that the current thread (from the pool) is blocked on a future related to a task in the pool, you can move it up the queue, or maybe even invoke on the blocked thread. Braddock suggested lazy futures, and I think that's also an important use case. For one thing, it shows that futures are useful without thread pools: you can use them in single-threaded code.
I don't quite understand you. What is the "current" thread in a thread pool? If there are dependencies between tasks in a thread-pool, shouldn't prioritizing be the task of an external scheduler - and solved before the tasks are initiated? I'd like to know your thoughts on what the thread pool should be and what problems it should solve more specifically than what's explained in N2276. I thought the most common use case for futures was the active object pattern. We should all try to agree what use cases/design patterns/higher level abstractions are most important and which we want to support. IMHO, this should be top priority for the "future ambition". Even though no higher level abstractions built on futures will make it to C++0x or boost anytime soon, it's important that the future interface needn't change to support them in the - future :) To me, being able to wait for any or all of a number of futures seems like an important use case. I'd use it to implement "i'm waiting on the result of a number of time-consuming commands and queries". Maybe this is implemented better in another way - any ideas? Anthony Williams-3 wrote:
This was alongside a suggestion that we change the names for condition_variable waits. The important part was the separation of timed_wait(duration) vs timed_wait(absolute_time) with distinct names, so it was clear which you were calling, and you wouldn't accidentally pass a duration when you meant a fixed time point.
We could go for timed_wait_for() and timed_wait_until(), but they strike me as rather long-winded. Maybe that's a good thing ;-)
Yes, long names is a good thing :) duration_timed_wait/absolute_timed_wait are other alternatives. duration and absolute_time will have two different types, right? If so I don't think they should have different function names because: - IMO it doesn't increase code readability to repeat type information in symbol names - It reduces genericity. Function overloading can be used to implement LSP for generic functions. template<class TimeType> void foo_algorithm(future<void>&f, TimeType t) { ... do stuff ... f.timed_wait(t); // LSP for TimeType, more generic } I vote for 2 x time_limited_wait. Best Regards, Johan -- View this message in context: http://www.nabble.com/Review-Request%3A-future-library-%28Gaskill-version%29... Sent from the Boost - Dev mailing list archive at Nabble.com.