Subj : Re: pthread function behavior in C++ program To : comp.programming.threads From : David Butenhof Date : Fri Jun 10 2005 08:52 pm wij@seed.net.tw wrote: > David Butenhof wrote: > >>HOWEVER, as POSIX does not actually provide any C++ >>language binding... >>... >>Similarly, as C++ says nothing about threads, you're left >>in a dark and sticky corner where any answer is entirely >>not just platform but release specific. > > This is a terrible news, as ALL C++ library/program have to > use C functions someway, i.g. open/close/read/write...they > would have the same upgrading labor. I take your word. It's not quite as bad, in general, as that. Remember I was talking specifically about cancellation. The whole point of the cleanup handler specification in POSIX was to mimic exceptions as closely as possible without language support. C++ has exception support, and getting a C++-unaware "thread library pseudoexception" system to interact with a C++ exception system may be non-trivial. On platforms with real native exception support (like, as I said, Tru64 UNIX and OpenVMS), you should expect any rational C++ runtime, and thread library, to use that support -- and indeed they do. That brings a basic level of interoperability. C++ has no name for a POSIX cancel, so you can't catch it by type -- but 'catch(...)' will work, and cancellation will run object destructors. While that's not quite as easy for systems without a common exception model, some other systems have implemented varying levels of integration between POSIX cleanup and C++ exceptions. (If you find a platform that doesn't, complain loudly. STANDARDS can come later, but we've had the need, and the users, for over 10 years now and there's just no excuse.) And aside from cleanup and exception issues, the picture is much better. There are few if any C++ compilers on POSIX thread systems that don't generate thread-safe code (most are also C compilers). There are a number of class libraries to help you get threading with objects. The biggest problem people have when getting started is in failing to realize that the POSIX standard, and its interfaces, are C not C++. That means for example that you can't pass a class member function to pthread_create(), or pthread_init(). You need a function with 'extern "C"' binding; you can pass an object by address (watch the casting!) to that function, and have IT invoke a method. While some compilers will let you pass methods, or 'static' class member functions, neither standard says that will work -- and since it is after all a C language interface the C++ standard says not to do it. The situation can get better, and there are C++ standards people working on defining how to make the C++ language better for threading; but it's not really all that bad now. -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .