Re: [Boost-Users] Re: boost::mutex::scoped_lock conventions

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-05-21 12:39:52

Alexander Terekhov said:
>
> Alexander Terekhov wrote:
>>
>> "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.
>>
>> How about moving this discussion to c.p.t.?
>
> Well, just in case... <Forward Quoted>

Thanks... I currently can't access c.p.t. in any reasonable manner.  I'm
working to rectify this, but in the mean time, I appreciate the cross
post.

> David Butenhof wrote:
>>
>> Alexander Terekhov wrote:
>>
>> >> > "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 cleanup issues are some of the bigger ones, IMHO.  And my experience
indicates there are a lot of people out there that Mr. Butenhoff would
consider "idiots", I think.  But I agree with what he's said.

>> 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.)

Most STL libraries are thread-safe today, so the analysis there wouldn't
be too difficult.  It just needs to be stated explicitly in the standard. 
Cancellation points are another issue... but I don't think C++ will add
too many to the list already provided by POSIX.

>> 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.

Absolutely agreed.  I've said all along that Boost.Threads has to be very
aware of what POSIX says.  We can not deviate in any way from POSIX that
will result in conflicts between the threading systems.

>> 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.

Agreed, but that's the case today when mixing languages.  There are a lot
of areas which are left unspecified, even when the languages being mixed
are C and C++.

>> 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.

No gaurantees.  But with a C++ definition, one can at least hope that
implementations will try and deal with these cross-language binding issues
in some reasonable manner.

>> 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".

Reasonable things for POSIX to do, or at least consider, IMO.

-- 
William E. Kempf