-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 02 June 2008 15:58 pm, Peter Dimov wrote:
I think that wait_for_any would be enough for such a scheduler. In pseudocode, the dependency-resolving thread
I didn't mention it, but I was thinking of a scheduler picking method requests and dispatching them using a single thread. At one extreme, you could create a thread that returns a future and then blocks on wait_for_any/wait_for_all in order to implement something that acts like future_select or future_combining_barrier, but it's less than ideal.
would do something like the following, in a loop:
set< future<void> > waiting_, ready_;
wait_for_any( waiting_ );
A scheduler which takes O(N) to dispatch a method request is considered inefficient. N being the number of pending method requests in the scheduler. The call to wait_for_any alone is O(N), thus my motivation for using future_selector for a scheduler. I'll let you in on a dirty secret: the scheduler I'm using now is O(N), but I'd hate not to be able to improve it to something respectable when I need to.
// for_each in waiting_ // if ready() move to ready_
// for each pending target // if dependencies are a subset of ready_, move to exec queue
// garbage-collect ready_ in some way :-)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIRF8+5vihyNWuA4URAj9LAJ4lsjOLJp0MvElF+rrgAg2DXl35UQCgoJH/ 1RUsOThKBrKVFjBJL026jUM= =fgK/ -----END PGP SIGNATURE-----