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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-25 16:32:44

Yuval Ronen wrote:
> Emil Dotchevski wrote:

>> If all of your code is in C++, you'd know not to call pthead_cancel
>> because it won't work. That would be no problem because you can work
>> at the C++ <thread> level where everything is nice and cool -- but
>> what if a 3rd party library built on <pthread> calls pthread_cancel?
>
> Then it would be a very bad library. A library should either create
> its own threads and then it is the responsible to join/detach/cancel it,
> or it works with thread created by the application and then shouldn't do
> any of those things. Just as Howard's example with
> malloc/free/new/delete - what happens if I pass a pointer created with
> new to a library which tries to deallocate it using free?

A thread can execute both C and C++ code. The analogy would be a block of 
memory that toggles itself between 'new' and 'malloc' mode at some arbitrary 
points, without giving you any indication as to what its current mode is.

> I'm really not familiar with the non-windows world. Is it really
> common for a library to call pthread_cancel on a thread not created by the
> application?

It doesn't matter who created the thread; it matters what kind of code it's 
executing. Unless you never call C code from C++ and vice versa, canceling a 
thread could prove quite hard. Consider a library with a C interface that is 
implemented in C++. The C application calls this library from its own thread 
and then pthread_cancels its thread. The C++ library is executing a call to 
fread and indirectly, read, which 'throws' a pthread cancelation. The 
library is left in an inconsistent and unusable state because the 
destructors of its beautiful RAII guards are not invoked. A few minutes 
later, when it's reentered, everything collapses. Welcome to a world where C 
is C, C++ is C++, and extern "C" is a bad joke.