Re: [boost] Boost.Threads, N2178, N2184, et al

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