[cpp-threads] Re: Thread API interface tweaks

[Lawrence Crowl]

Rather than try and collect quotes and so forth, I will just make a
couple of comments.

The distinction between class thread and class thread_id seems excessively
complex.  Why should we have thread at all?  Why not just thread_id?
The storage can be deallocated after completion of the join operation,
which is essentially equivalent to new/delete.

Futures are a very valuable facility, too valuable to be tied to threads.
They should be a separate facility that happens to also work with threads.

    In particular, if the join operation has a function-call form, then
    a future that relies on only that form will work with both threads
    and regular functions.  For regular functions, the future can act
    as memoization. Even void futures make sense, they can be used for
    "log any use of this program feature".

    I note here that we probably want two types of futures, one for
    sequential access and one for concurrent access.

    Both threads and futures require some ability to store and rethrow
    exceptions for full generality.

We already have a keyword __thread, and I think that defining a type
named thread will lead to confusion.  The joiner terminology at least
does not have that problem.

Most large applications live in a multi-language world, and like it or
not, C is the common glue that binds them together.  Therefore, I would
like to see the C interface for manipulating a thread - yield, sleep,
mutexes, etc.  I do not think we can reliably leave that task to later.
I think we can probably get away with thread creation in C++ requiring
thread joining in C++, and of course scoped locks unique to a language,
but the other operations need C interfaces.

For those wondering about email addresses, I am on the cpp-threads
mailing list, and so do not need to be listed explicitly as an addressee.

-- 
Lawrence Crowl