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> 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 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".
-- /--------------------[ David.Butenhof@hp.com ]--------------------\ | Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/
regards,
alexander. < playing "arabic telephone", an electronic one ;-) >
--
"// Possible implementation for