Vicente Botet Escriba wrote:
However, thread pools do not aim to provide good latency which might make a such future implementation useless for scheduling related usage (which might still be ok since it could be the best design option we have). I'd love to hear the authors views on this.
Could you develop the use case you have in mind.
I'm thinking about libpoet, asio and the scheduling related use cases from Gaskill's documentation. Vicente Botet Escriba wrote:
Actually, I started writing a reply but I couldn't really understand your implementation. I was hoping one of the authors would reply first and I could join in later. To solve the complexity problem, I agree we need to expose some stateful abstraction and can't do with just free functions.
Replay to the post. Let me know what you don't understad.
I'd like acknowledgement from Anthony - that he too thinks the complexity is a real problem - before trying to solve it. Vicente Botet Escriba wrote:
If we choose require a third thread (or thread pool) for future composition, I'm sure there are lots of nice interfaces like your proposal above. I don't want to spend too much time designing these fancier features now though.
Which other features would you want?
As few as possible :) I hope we can accept a minimal library first, then let real users' need dictate the features. 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. Cheers, Johan -- View this message in context: http://www.nabble.com/Futures---Reviews-Needed-%28January-5%2C-2009%29-tp212... Sent from the Boost - Dev mailing list archive at Nabble.com.