Alexander Terekhov wrote: > > "William E. Kempf" wrote: > [...] > > >> 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, > > http://news.cis.dfn.de might help. ;-) > > but in the mean time, I appreciate the cross > > post. > > I'll wait a day or two and post a reply addressing some of your points > to comp.programming.threads.
"just in case..." <Forward Inline> Alexander Terekhov wrote: > > <Forward-Quoted source=Boost> > > "William E. Kempf" wrote: [...] > > >> 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. Well, <http://lists.boost.org/MailArchives/boost/msg47701.php>. > > 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. The current C++ Std is in conflict with POSIX, to begin with. The C++ standard says that almost the entire C library doesn't throw (in effect, everything is throw()) except just a few calls for which C++ headers provide extern "C++" overloading to facilitate C++ callbacks. In POSIX, a whole bunch of standard C library functions DO "throw" due to thread cancelation. Isn't that funny? > > > > >> 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. Bill, Boost.Threads shall end up in standard <thread> header. But there should also be a <cthread> standard header (it should penetrate ISO C as well; in the form of either <pthread.h> or <cthread.h> header). Now, in the past, I was thinking of <thread> as "just" an object layer on top of <cthread> stuff. That was wrong. <cthread> should be fully implementable using stuff from <thread>. I mean things along the lines of: typedef std::thread * pthread_t; extern "C" pthread_t pthread_self() throw() { return std::thread_self().raw_ptr(); } typedef thread_specific_ptr<void, __c_TSD_cleanup> * pthread_key_t; extern "C" int pthread_key_create(pthread_key_t * key, void ( * dtor)(void *)) throw() { try { // can throw "shall fail" stuff only (std::bad_alloc and std::try_again) *key = new pthread_key_t(__c_TSD_cleanup(dtor)); // "may fail" shall be caught in the std::unexpected() handler } catch(...) { return __translate_exception_to_error_code_using_throw_and_catch(); } return 0; } typedef std::aligned_storage<std::mutex> pthread_mutex_t; typedef std::aligned_storage<std::mutexattr_t> pthread_mutexattr_t; extern "C" int pthread_mutex_init(pthread_mutex_t * mutex_storage, const pthread_mutexattr_t * attr_storage) throw() { try { // can throw "shall fail" stuff only new (mutex_storage->place()) std::mutex(attr_storage->object()); // "may fail" shall be caught in the std::unexpected() handler } catch(...) { return __translate_exception_to_error_code_using_throw_and_catch(); } return 0; } extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage) throw() { // destructor with implicit throw()-nothing ES ~mutex_storage->object(); // "may fail" shall be caught in the std::unexpected() handler return 0; } #define PTHREAD_CANCELED std::thread_canceled() extern "C" void pthread_exit(void * ptr) throw(std::thread_termination_request) { (ptr == PTHREAD_CANCELED) ? std::thread_cancel() : std::thread_exit(ptr); } using stuff from <thread>: struct thread_canceled { operator void * () { return &unique; } static thread_canceled unique; }; template<typename T> void thread_exit(T value) { assert(std::thread_self().can_exit_with<T>()); throw thread_exit_value(value); } template<> void thread_exit(std::thread_canceled) { thread_cancel(); } void thread_cancel() { throw std::thread_cancel_request(); } or something like that. > > > > >> 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++. C and C++ WILL merge, sooner or later. The separation of C and C++ languages is/was the stupidest thing C++ authors ever did (or allowed to happen). Well, just look what's going on with respect to GCC/G++ (adding exceptions and C-destructors IS kinda "merging", I believe). > > > > >> 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. *You* should do it for "C subset of C++" (incompatibilities and "restrict"-like extensions of ISO-C aside for a moment). There will be NO problems with cross-C/C++-language bindings if Boost would come up with some "reference implementation" (see above) of <cthread> (i.e. also <pthread.h>) using stuff from the REAL <thread> header. You did not seem to like to "force" windows user of Boost.Threads to download pthreads-win32 and use Boost.Threads on top of it. YOU'RE RIGHT! Pthreads-win32 will be shutdown as soon as you'll deliver a <cthread> and <pthread.h> beasts implemented using stuff from the "boosted" <thread>. And, perhaps, then even Microsoft will follow... delivering a much better implementation of BOTH (including fully supported cancelation for all C and C++ standard calls meant to throw std:thread_cancel_request exception). > > >> 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. Hardcore POSIX folks don't really "think C++", unfortunately. The only way to get it done is to deliver POSIX threading API implementation "on top" of Boost.Threads to them, I think. Well, this would also mean a whole bunch of extensions to the current POSIX threading -- things like parameterized pthread_once() and TSD destructors (to support shared_ptr like "custom deleters" without too much overhead), etcetera. What do you think? regards, alexander. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
