On 5/1/06, Beman Dawes <bdawes@acm.org> wrote:
If you haven't done so already, be sure to look at Ion Gaztañaga's implementation in the Boost Vault of Kevlin Henney's N1883 futures design. It is under active development.
--Beman
I'm aware of the futures in active development, though my library is unique with respect to other active function and active object implementations in that it avoids the concept of futures almost entirely, or rather, merges the concept of futures with the concept of a running asynchronous function (represented by an action in the library) and the concept of active objects as conceptual return types of asynchronous calls rather than "future" values. By that I mean in order to create an active function call, you merely instantiate an action, passing the function object and arguments to the constructor. Access to the return value is granted through the action indirectly with * and -> but the interface of the value is actually the associated active qualified form of the return type and so operations performed on it are all serialized and do not imply a wait, even for complex user-defined types. Basically, instead of futures, the return type is thought of as an active type whose thread is not created until operations on it are queued. This provides a superset of the functionality provided by futures as you can still get the "inactive" form of the return type and force a wait for any type, however such a loss of concurrency is not necessary for any type which has a well-defined active interface, including complex user-defined types. -- -Matt Calabrese