Sorry if this question has a obvious answer. It is sure that the destructors will be called when a process is killed?
Sorry, I explained incorrectly. There is nothing obvious about these complex system programming issues.
You can translate into exceptions most of the "problems" that will cause a process to terminate. Access violation, division by zero, stack overflow, etc.
This way you can make sure the destructors are called thanks to stack unwinding. This is not a silver bullet but you will have some sort of cover. On top of that, if you add a handler for memory allocation error, you have yourself a reasonable guarantee that you will fail gracefully.
Of course when the process is terminated by the OS, nothing is called. From the kernel point of view, a process is just a structure with handles referencing kernel objects. When it says... "DIE !", all threads cease to be scheduled, virtual memory gets unmapped and everything created by the process is destroyed, except, as you noticed, shared objects such as a named mutex.
Since your threads are no longer scheduled, no chance that the code of your destructor is run. Dang! It's not even referenced by the VMM anymore! AAAaahhhhh. Tar pit.
If the process terminates by itself, functions registered with atexit and destructors of static variables are called.
Now the question is against which kind of process termination do you wish to protect yourself? On which platform?
If you wish to protect against the user terminating your process there's not much you can do as Ion explained. Even in this situation you can do something. After a thread (or a
Edouard A. wrote: process) which holds a mutex locked gets killed any attempt to unlock the mutex will (and should) fail with EPERM. To resume using the mutex you can initialize it again. In other words, you can invoke pthread_mutex_init() on this mutex. This will unlock the mutex for you. This is sort of a dirty trick. If a thread had a mutex locked when it was killed it is very likely that the data (that the mutex protects) is in some inconsistent state. So, besides unlocking the mutex (by the means of pthread_mutex_init()) you also have to restore the data.
You can remove termination rights, but again, if the user has got root/administrator privileges it can just sudo his way to your demise.
Kind regards.
BR, Dmitry