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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk