[cpp-threads] Asynchronous Execution Issues

[Beman Dawes]

On Fri, Apr 24, 2009 at 4:39 PM, Lawrence Crowl <Lawrence at crowl.org> wrote:
> At the Summit meeting I took the action item of producing a proposal
> for a simple asynchronous execution.  The idea was to facilities,
> with an API along the lines of:
>
>    auto x = std::creating_async( function1 );
>    auto y = std::caching_async( function2 );

I'm having a lot of trouble with this interface. It appears to
hard-wire in two particular async managers, namely a creating manager
and a caching manager.

I was expecting a generic algorithm for passing a function concept
object to an async manager concept object, not a set of hardwired
functions that will have to be extended for every new async pool
management technique that comes along.

One way of doing this, and I fully expect this group to be able to
come up with a generic approach that is even better, would be for the
async() function to be a template, with a second template parameter
that specifies the type of the async manager to be used, and a second
function argument that supplies a reference to an instance of that
async manager type. I was expecting the second template parameter to
default to something like creating_async_manager, and the second
function argument to default to default_creating_async_manager().

What am I missing? Wouldn't such a generic approach allow us to
provide one or two very simple managers, thus keeping the Kona
compromise and not breaking the schedule, yet provide great
encouragement for the development of more capable thread pool managers
over a period of time? We could even add a note indicating flat-out
saying that.

Of course there isn't any point in discussion a generic approach if
the other problems raised in this thread can't be solved in time. But
I do want to raise the question of a generic versus hard-wired
interface design so that we can also be thinking about that issue.

--Beman