-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 May 2008 04:54 am, John Maddock wrote:
With apologies for coming to the discussion late, it seems to me that many future implementations including the ones under discussion are high level interfaces that are "feature rich". Nothing wrong with that, it's exactly what a lot of folks need.
But I would also be interested in a super-lightweight future used for more low-level task-based parrallelism. In my dreams <g>, it would be something like:
* Create a scoped object that executes the "future" in parrallel, constructing the object would be no more expensive than a trivial function call - so no memory allocation or mutexes allowed, only lock-free programming. * The future would be executed using a thread drawn from a pool - or possibly a local team - so there's no thread creation overhead either (except at program startup, or possibly the first time a future is invoked). * At a later point in the same scope, join with the future, again this should be a "trivial" lock-free operation if the future has completed.
So... is such a beast possible? Or are threads actually too heavyweight for such usage?
You seem to be describing something closer to an active object than a future. The primary responsibility of a future is not to execute code (although we have been discussing callbacks which would allow that). Its main job is just to provide a handle which can be used to conveniently obtain a result that may not exist yet (and might be produced in a different thread) in a thread-safe way. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILZKp5vihyNWuA4URAqBFAJ9Rh/YpLUgnJ7pbcLr8V+ggZdL59wCfXRGN C7HMaengDIl/926aBTi0HLU= =EUKU -----END PGP SIGNATURE-----