On Mar 25, 2007, at 12:03 AM, Emil Dotchevski wrote:
Connection between pthreads and C++ threads: The critical connection > is cancellation. If you phthread_cancel a C++ thread, what happens? > If you thread::cancel() a pthreads thread, what happens? In the ideal > world everything would just work. I'm not convinced this is > practical.
We can say "oh well, whatever" and not standardize what happens when thread cancellation crosses the C/C++ language barrier; however this approach doesn't work where the rubber meets the road: at some point, someone will have to define these semantics. Without a standard, the implementation-defined semantics (as of today) vary from platform to platform; I do not see how this is helpful.
If I implied that the current state of pthreads cancellation and how it behaves in C++ is a good thing, then I sorely miscommunicated. Below I try to improve... A standards body is nothing more than a mediator among multiple vendors and their customers. We can help by making agreements, nothing more. The standards body holds no enforcement power over any of the agreements. If agreements are made which a significant percentage of the participants find unworkable, the standard has failed. Now add to this: adopting pthreads cancellation in C++ not only involves C++ vendors and their customers, it also involves the cooperation of the C and Posix ecosystems (standards bodies, vendors and customers). And again, I am not saying this is impossible. I'm only saying that it is daunting. I am not saying it is so daunting we shouldn't even try. I'm simply trying to clarify the hurdles that lay before such a project so that we can all discuss it in a more informed light. On the positive side: a universal, language-neutral exception model would be a wonderful thing. Indeed I believe this is the model that Microsoft has implemented on Windows. In unifying pthreads cancellation and C++ cancellation I believe the second easiest platform to do this on would be Windows (Tru64 UNIX would probably be the easiest since they built it that way from the start). The problematic platforms are those that have already adopted C (without exception propagation support) and pthread cancellation not based on exceptions. On these platforms, when C++ code calls C code (say fclose), it knows a-priori that an exception will not come flying out of that C call. And yet on this same platform, C/Posix clients may well expect to be able to cancel code that calls fclose (again just using fclose as an example). So if this platform wishes to bring threading to C++, complete with a unified model of cancellation, it is going to have to upset either its C customers or its C++ customers. Either fclose still does not propagate exceptions (i.e. it can not be cancelled), resulting in no change for the C++ customers but a change for the C customers. Or fclose can propagate exceptions: a change for the C++ customers, no change for the C customers. Today C++ customers on this platform are not using pthread_cancel at all. It is impossible to do so because destructors don't get run. A further possible problem (I am not positive) is that this platform (which currently does not support unwinding exceptions through C stack frames) would have to undergo an ABI breaking change for its C customers to change to a model in which it can propagate exceptions through a C stack frame. In essence, we're asking the C community to standardize the semantics of try/finally (no catch, no throw) operating with C++ exceptions. This is a *huge* request requiring a significant buy-in from a huge number of people who may have no particular interest in C++. And then there's the Posix committee to deal with <sigh>. To a significant portion of that population the idea of cancellation resulting in a catchable/swallowable C++ exception is nothing short of blasphemy and it is extremely challenging to get past that one point in any discussion. It is in this context that completely independent cancellation mechanisms for C/Posix and C++ begin to look like an attractive alternative. If you've got a C thread, cancel it with the C mechanism. If you've got a C++ thread, cancel it with the C++ mechanism. There is precedent for such a division being a workable compromise: new/delete/malloc/free. -Howard