[cpp-threads] Asynchronous Execution Issues

[Lawrence Crowl]

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 );
    ....
    auto a = x.get();
    auto b = y.get();

The difference between the two is that creating_async would always
create a new thread, while the caching_async is permitted to reuse
threads.  The primary operational difference is that thread-local
storage is reused in the latter case.

There are a couple of issues that make the task more difficult than
we thought at the time.  As a result, I have a couple of questions.

First, consider the case of the caching_async.  Because the threads
may persist, we need a handle on the list of threads so that we
can inform a thread to die so that we destroy any thread-local
variables before the global variables that they reference.  So, we
start needing a manager object, and the whole facility is starting
to look too much like a thread pool.  I don't feel as though I have
a mandate to propose anything that looks like a thread pool.  Do
you agree?

Second, consider the case of the creating_async.  The problem here
is a touch more subtle.  In particular, once the working thread has
set its promise, it can start destroying thread-local variables.
Unfortunately, we have no idea when that has or might happen.
That thread could be stalled immediately after providing the value.
The solution is to wait for thread termination before returning the
value from the future.  This solution implies keeping the thread as
part of the future so that we can wait.  We have no such mechanism.
So, an asynchronous execution function needs another kind of future.
Is such a future going beyond my mandate?

-- 
Lawrence Crowl