From: Braddock Gaskill (braddock_at_[hidden])
Date: 2008-04-13 18:55:18
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
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
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.