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

[Alexander Terekhov]

David Abrahams wrote:
[...]
> Fortunately, the question may be moot: is there really much we *can*
> do with a C++ binding in order to "accomodate" cancellation-safe C
> code? ...

Well,

http://google.com/groups?threadm=3ecb86f7%40usenet01.boi.hp.com
(Subject: Re: __attribute__((cleanup(function)) versus try/finally)

<quote>

>> > "William E. Kempf" wrote:
>> The motivations are backwards here, though.  If the C++ language 
>> adopts a threading library, POSIX systems will have a lot of 
>> motivation for defining a POSIX C++ binding, or at the very least, 
>> making a particular implementation's POSIX binding compatible with 
> the C++ threading.

Right now, the C++ language has, by default and convention, a POSIX 
binding; 1003.1-2001. The C and C++ languages are sufficiently 
interoperable that this presents only a few restrictions on the use 
by C++ code, around exceptions and member functions. OK, so the 
thread start routine needs to be 'extern "C"' -- a minor 
inconvenience. OK, so there's no portable standard on 
interoperability between POSIX cleanup and C++ exceptions, and I'll 
resist suggesting that only an idiot would fail to make them 
completely compatible and interoperable; but at least most people 
can be educated to realize that they ought to be.

The big hurdle for a true C++ binding is that the current state of 
affairs is "good enough" for most people, and the political process 
of developing a full native C++ binding would be painful. (Remember, 
it's not just saying that the thread::create method takes a class 
member at which the thread will start... it means reviewing every 
method and template in the STL to determine which have thread 
safety requirements, and deciding precisely what those requirements 
are and how to meet them. Then there's the matter of cancellation 
points... and so forth.)

When and if the C++ standard adds true thread support, that will be, 
by default and in practice, the thread binding for C++; whether the 
underlying thread environment is POSIX, Win32, or something else. 
This is great, as long as it doesn't do or say anything stupid, but 
it still leaves a few loopholes because inevitably people will 
continue to write applications that mix languages. Mixing C and C++ 
has never been a problem; but if the thread model in C++ is 
radically different, it could become a problem. Furthermore, there's 
a missing piece that neither POSIX 1003.1-2001 plus ISO C++ 2005 (or 
whatever), or even 1003.1-2001 plus a hypothetical "1003.C++" will 
necessarily (or even likely) supply -- and that's how the two 
interoperate.

If C++ or 1003.C++ says that thread::cancel raises an exception, 
and 1003.1 says that pthread_cancel() invokes cleanup handlers, 
does that mean that cancelling a thread with pthread_cancel() will 
trigger catch(...), or even destructors? Well, maybe not. This 
could more easily be solved with a 1003.C++, perhaps, since at 
least the two standards are in a family. Since the C++ standard is 
unlikely to mention POSIX any more than now, it's unlikely to 
provide any guarantees.

Perhaps that would provide an opportunity for a smaller POSIX 
project, though; a PROFILE that would chink the holes where the 
two walls meet. In effect, specifying a "POSIX platform" 
supporting both threads and C++ that simply says "C++ 
cancellation is the same as POSIX cancellation", "POSIX cleanup 
handlers are logically and semantically the same as C++ object 
destructors", and "POSIX cancellation is visible as a C++ 
exception".

</quote>

regards,
alexander.