Yes, I suppose that the whole application would be a single thread world using that analogy. Objects are not 'bound' to a particular thread, they can be accessed freely from any thread and the user is responsible for protecting them - or preferably writing functional-like code to avoid
collisions etc.
HPX uses executors to fine-control where which task is executed. Every function which (potentially) creates a new task can optionally be used with an instance of an executor (async(), future::then(), etc.)
Are we reviewing HPX? Sorry Hartmut if I gave the impression of comparing Asynchronous to HPX.
I was not under the impression that this was a formal review of Boost.Async. I rather was trying to understand the specifics of Boost.Async and therefor I was comparing it to something I know ;)
IIUC it is a library written by a private company and not intended for boost inclusion.
Just to rectify this: HPX is not a product of a private company. It's just a large open source project distributed under the Boost license with many (very capable) people contributing, which because of its scale and the produced code quality might have created your impression of it having a commercial background. The reason why it's not considered for Boost inclusion is simple. Nobody has stepped forward to make that happen. We'd be happy to support anybody interested in pushing such an avenue.
I mostly care about std::async and the proposed Standard extensions for futures. I'm not the one who brought HPX to discussion.
That was John B. IIRC, he was asking why you have decided to create your own library instead of joining forces by contributing to HPX based on his impression that Boost.Async provides services very similar to HPX. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu