Re: [boost] [interprocess] locked mutex and process killed

Subject: Re: [boost] [interprocess] locked mutex and process killed
From: Edouard A. (edouard_at_[hidden])
Date: 2009-03-24 18:49:02

> > Well the destructor of the scoped_lock calls unlock, or am I missing
> > something?
> 
> 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. 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.

-- 
EA