Subject: Re: Out Of Memory conditions
From: Mike Nordell (tamlin@algonet.se)
Date: Sat Feb 03 2001 - 13:42:47 CST
Many misconceptions seem to sneak their way into this discussion. Not to
mention mixing Unix, POSIX and C++. I'll try to make it clear in this post.
Mind you, everything I write in this post is "AFAIK".
Sam TH wrote:
> Well, you said that abort() is what gets called on an uncaught
> exception.
Yes, that's the behaviour of the default new_handler.
But we can change that behaviour, by installing our own new_handler
function, to _not_ throw an exception (since exceptions are simply not
allowed in abi code). That would be the reason to install a new_handler, to
make it emergency save instead of throwing a bad_alloc exception (for
conforming compilers, MSVC simply returns 0 by default :-<), and _then_ call
abort() or exit() (the default new handler calls abort(), but AFAIK it is
allowed to call exit() instead, if that would "help" us).
> I *think*, and I may well be wrong, that the Unix signal
> handling code currently catches abort.
abort() is a function. The Unix (or should we say POSIX to be correct?)
signal handling does not kick in when calling functions. abort() don't
raise() signals.
> However, even if it doesn't, it can.
How?
> Then we wouldn't need to worry about this (on machines with
> POSIX signals). It still seems like a reasonable idea for windows.
Well, MSVC[6] _does_ support a few of the POSIX signals. It even supports
SEGV, even that the documentations tells you otherwise!
But since this is starting to drift away from C++ vs. non-C++ into POSIX.n
(where n is currently arbitrary) vs. non-POSIX or partially-POSIX, maybe we
should try to be as C++ conforming as we can be?
What about creating a compiler-specific startup function that calls the
set_new_handler (whatever it's called in any non-conforming compiler) and
that handler function then calls our emergency-saver?
/Mike
This archive was generated by hypermail 2b25 : Sat Feb 03 2001 - 13:41:01 CST