-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 details) 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. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIK0AR5vihyNWuA4URAk/8AJ9P/AMkQhvs6bcOTxlNy3ZdQ3ddygCgyt4o qeFQZocP8r4yd7G+sBIt310= =lkFA -----END PGP SIGNATURE-----