From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-25 11:46:09
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