[c++-pthreads] C++ and posix threads

[Alexander Terekhov]

Jean-Marc Bourguet wrote:
[...]
>  - need the collaboration of the pthread library or be implementable
>    as wrapper around an existing pthread library?

Pthread library shall use/throw C++ exceptions for thread cancel 
and thread exit (without <thread>, we can exit with only void*). 
"Collaboration" (see below) would be really nice and is probably 
the best way to provide both <pthread.h>/<cthread> and <thread> 
interfaces. 

>  - allow modifications to the C interface visible from C or not?

No changes except just a few extensions -- see (3) below.

>  - allow modifications to the C interface visible from C++ or not?

Nothing but extensions to C interface and changes (3) to C++:

1. "Visible" C++ exceptions for thread cancel and thread exit 
   (ability to "intercept" thread cancel/exit);

2. Ability to re-enable cancelation after thread termination has 
   been initiated (thread cancelation state was set to disabled 
   by the implementation). 

3. Mandatory 2-phase EH and sort of "intelligent" cancelation 
   points -- they shall NOT throw thread_cancel_request exception 
   if no matching handler is found in the dynamic context... such 
   as invocation of C cleanup handler via pthread_cleanup_pop(1). 
   And all C++ dtors should have an implicit throw()-nothing ES, 
   of course. For C++, that would also mean "some" changes in ES 
   semantics which are currently pretty much totally busted, BTW.

[...]
> Terekhov is apparently somewhere in between

Well, I'm not really in between. <thread> would simply provide 
much better C++ interface... in addition to the "classic" one
(<pthread.h>/<cthread>). It's just like <iohw.h> (<pthread.h>)
and <hardware> (<thread>): 

http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n972.pdf
http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1457.pdf

<quote>

Obviously, interface definitions written in the common subset
of C and C++ would have the widest potential audience, since
they would be readable by compilers for both languages. But
the additional abstraction mechanisms of C++, such as classes
and templates, are useful in writing code [...]. They allow 
the encapsulation of features into classes, providing type 
safety along with maximum efficiency
through the use of templates.

Nevertheless, it is an important goal to provide an interface
that allows [...] to write code that compiles equally under C 
and C++ compilers. Therefore, [...] specifies two interfaces: 
one using the common subset of C and C++ and a second using 
modern C++ constructs. Implementers of the commonsubset style 
interface might use functions or inline functions, or might 
decide that function-like macros or intrinsic functions better 
serve their objectives.

[...]

The implementation of the [... C ...] interface on top of the 
<hardware> interface is mainly straightforward. This section 
provides an example of how such an implementation can be 
achieved.

</quote>

regards,
alexander.