[cpp-threads] Re: Thread API interface tweaks

[Peter Dimov]

Lawrence Crowl wrote:
> On 8/29/06, Peter Dimov <pdimov at mmltd.net> wrote:
>> Lawrence Crowl wrote:
>>> 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 "vote" for <pthread.h> and <sched.h> being that C interface. This
>> saves a lot of standardization work. :-)
>
> There are some problems with this approach.

There are problems with every approach, but this one has benefits, too. :-) 
POSIX is a standard, a fact of life, and the basic threading API on which 
most of our C++ primitives will be based. If we adopt it as part of C++,

1. We can incorporate it by reference (with a couple of extern "C++" changes 
here or there).

2. We will acknowledge its existence and define the semantics of programs 
that mix <pthread.h> and C++ threading primitives. Such programs are likely 
to be common, given the current adoption of POSIX threads.

3. We won't have to duplicate each and every facility in the high-level API 
(sched_yield, for example.)

4. We can use <pthread.h> structures in the high level API.

5. Microsoft platforms will, hopefully, gain an official POSIX threads 
implementation.

6. Everyone else gets to sit back and relax as they already have it 
implemented. :-)

> * The data structures would necessarily need to contain types
> acceptable to all languages.  You wouldn't be able to use std::mutex,
> and so the C++ mechanisms being proposed would be completely
> unusable.

This is an interesting point, but doesn't it apply only to interfaces? It 
would still be possible to use std::mutex in library X and pthread_mutex in 
library Y.

> C++ is successful in large part because it was able to live within
> the existing environment.

In this case, <pthread.h> _is_ the existing environment. :-)