Alexander Terekhov said:
Alexander Terekhov 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
"William E. Kempf" wrote: [...] 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