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.