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
