Re: What risk of undefined behavior if destructor must throw?
Earl Purple wrote:
kanze wrote:
I'm not so sure. If you actually do hold the mutex, and for
some reason, the system cannot release it, your application
is hosed. About all you can do is get out as quickly as
possible, so that the backup can take over. (I can't
actually think of any case where this is possible, and
Solaris doesn't provide an error condition for it. But who
knows.)
On Solaris it presumably isn't possible. The call will fail
either if the argument is not a mutex at all or your thread
doesn't own it.
By "not a mutex at all", I presume you mean cases like when the
pthread_mutex_t object was never initialized, or when someone
scribbled all over it because they forgot to initialize a
pointer. If that's the case, yes, you've covered all of the
cases (or at least, all I know of, and all that are documented).
I think that this is a characteristic of all, or almost all,
machine local resources.
Also on Solaris it's possible to have a recursive mutex such
that even if you call unlock on it, it's not guarantee that
you have unlocked it because it uses reference-counting. (This
can be useful for making RAII lock objects copyable but I
don't actually use them myself, my lock objects are movable
but not copyable).
Interesting. I hadn't thought of the use of this to support
copying. I don't use recursive mutexes, and until now, had
pretty much looked down my nose at those who did. But I think
you've just indicated a valid use of them.
If you don't hold the mutex, but thought you did, then there
is probably a serious violation of your preconditions in the
preceding code, which also calls for getting out as quickly
as possible.
That's what asserts are for. In release mode I would not want
an application to terminate for some reason that may not even
be fatal. I could lose all my work. Or if it's a server,
business could be lost.
That's what asserts are for, correct. And you never compile
asserts out unless the profiler says you have to. If an assert
triggers, it means that you're too late, that your program is
corrupted. And that any further actions (including what might
take place in a destructor) have a definite risk of making
things worse.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]