Re: [boost] Re view Request: future library (N2561/Williams version)

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-12 06:14:31

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-tp16600402p17184676.html
Sent from the Boost - Dev mailing list archive at Nabble.com.