On Sun, 13 Apr 2008 15:54:08 +0300, Peter Dimov wrote:
I have some more questions related to the callback support.
1. If thread A is blocked waiting for a future and thread B puts a value into the promise, is A unblocked right away, or do the callbacks complete first? In other words, is A guaranteed to observe the side effects of the callbacks?
Hi Peter, No, someone waiting on the future is not guaranteed to see callback side-effects. All listeners are notified and the future_impl mutex unlocked before the callbacks are called.
2. What is the motivation for allowing more than one callback? This turns the promise into a signal.
Hehe, I go back and forth on one or many callbacks every time I revisit the design - last time being last week. My justification is that add_callback() is really needed for authors of other frameworks to hook into things (see prior post on guards and operators). My fear with only one callback is that, for example, ASIO adds future support, uses add_the_callback internally, and later a user of ASIO uses add_the_callback for his own purposes and breaks ASIO. I have considered making add_callback a friend function in a separate future_ext.hpp header just to distance it from standard future<> usage. It is really only necessary to make the library extensible. Braddock Gaskill