From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-14 15:40:00
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 14 May 2008 08:57 am, Johan Torp wrote:
> Anthony Williams-3 wrote:
> > Alternatively, you could do it with a
> > completion-callback, but I'm not entirely comfortable with that.
> I'm not comfortable with this either, for the reasons I expressed in my
> response to Gaskill's propsal.
> This issue is my biggest concern with the future proposal. The alternatives
> I've seen so far:
> 1. Change/alter condition variables
> 2. Add future-complete callback (Gaskill's proposal)
> 3. Implement wait_for_many with a thread per future
> 4. Implement wait_for_many with periodic polling with timed_waits
> 5. Introduce new wait_for_many mechanism (public class or implementation
> 6. Don't ever support waiting on multiple futures
> 7. Don't support it until next version, but make sure we don't need to
> alter future semantics/interface when adding it.
> Alternative 7 blocks the possibility to write some exciting libraries on
> top of futures until a new future version is available.
In my libpoet scheduler code I described in an earlier post today, I currently
use the a future-complete callback (signals/slots more specifically).
Although I could make my scheduler work with wait_for_many support instead,
it would be more cumbersome and less efficient.
First, with signals/slots I can avoid having to make the scheduler thread wake
up every time any input future of any method request in the scheduler queue
becomes ready. Instead the individual method requests can observe their
inputs, and only generate invoke a signal in turn when all of their futures
are ready. Then the scheduler only has to observe the method requests and
doesn't have to wake up (possibly spuriously) and check every method request
in its queue every time a single input future becomes ready.
Second, if all I can do is wait for multiple futures, then the scheduler has
to additionally maintain and keep updated a separate container with all the
input futures of the method requests currently queued.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk