Re: WIN-18: remove exception.cc dependancy on libstdc++-v3 headers

[Jeff Sturm <jsturm at one-point dot com>]

On Mon, 11 Feb 2002, Andrew Haley wrote:
>  > (I know the abort isn't supposed to occur, but consider that my Java
>  > applications runs 24/7 and I'd prefer it to limp along in a crippled state
>  > than quit completely.
> 
> That depends.  When the EH is totally corrupted it makes far more
> sense to abort: at that point a 24/7 app would need to be restarted
> from its last checkpoint.  That's the only secure thing to do in such
> a situation.

You may be right.  Suppose the thread's stack is corrupt.  I could abort
the thread and possibly continue safely, but unless I can run cleanups and
release monitors, the application could be in a bad state.

If the dwarf info is corrupt we are really hosed.  Too bad .eh_frame is
mapped to a writable segment.

>  > Even with Sun's VM I get a MTBF of about 1 month; I'm hopeful that
>  > gcj can do better.)
> 
> Sure, but continuing with a broken EH context is not how you get
> reliability.

I'm wondering how it is really different from stack overflow or OOM, none
of which are easy to recover from.

But never mind, I was just thinking out loud.

Jeff