Re: [boost] [future] Early draft of wait for multiple futures interface

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-30 09:25:43

Anthony Williams-4 wrote:
> 
> Alternatively, you could have future_or spawn a thread to run the task
> rather than do it lazily as a wait callback.
> 

I don't think spawning a thread is acceptable.

1. Starting a new thread is expensive. Thread-pools might help here but they
don't exist yet.
2. Context switching is expensive. Typically, the evaluation work is real
small. This approach requires an additional context switch compared to if
the future-listener performed the evaluation. It might also reduce the
performance of a thread-pool if composite futures are frequently evaluated. 
3. Composed futures might need to access data belonging to the
future-listener in it's evaluation. If the evaluation is performed by a
single future-listener, it can use const references. Now such the data needs
to be copied or protected by mutexes.
4. Nested composed futures might get a context switch at every depth level.

I wouldn't be surprised if the context switching would rule out futures from
libraries such as asio or poet. That would be a real shame. Frank or
somebody with asio insight, what do you think? 

I'm also not convinced that we want a wait callback. I'm not sure "thread
stack re-use" is such a good idea. As I pointed out before, it can spread
dead locks to client threads in very unexpected ways, for instance by
violating lock acquistion orderings. Library support for fibers or even
language support for co-routines are cleaner alternatives, I suppose they're
quite difficult to add though.

Johan

-- 
View this message in context: http://www.nabble.com/-future--Early-draft-of-wait-for-multiple-futures-interface-tp17242880p17558832.html
Sent from the Boost - Dev mailing list archive at Nabble.com.