From: "Paul Derbyshire" <pderbysh AT usa DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Exceptions
Lines: 74
Organization: The Chaos Zone
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <Az281.1365$qR3.5658521@news20.bellglobal.com>
Date: Mon, 18 May 1998 22:25:36 GMT
NNTP-Posting-Host: 206.172.228.63
NNTP-Posting-Date: Mon, 18 May 1998 18:25:36 EDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Can anyone tell me the details of exception handling in gcc 2.8.1, and its
implications for threaded code?

-- Original Message --

Typically, you will have to write some low-level compiler-specific code
to get exceptions to be thrown correctly.

There may be exception global variables that you may need to treat opaquely
(just memcpy them) during your ThreadSwapIn and ThreadSwapOut routines.  Or,
there may be published "exception_thread_swapin" and
"exception_thread_swapout" functions published by your compiler.

When building code for exceptions, each stack object will typically be
put onto a stack of objects to destruct when unwinding the stack frame
because of an exception.  This exception stack is not the real CPU stack.
The C++ code must be aware of what destructors to call when an arbitrary
function f() throws an exception past any stack frame.

The link pointer may be sitting on the C++ stack next to the object that
you have constructed, for example, and the exception_top_stack may be
a global.  Unless these exception globals are in registers, you'll
need to save+restore the exception global memory for exceptions to
be handled correctly.

The simplest case of the problem is:

   Thread A                    Thread B
---------------             --------------

   Object a;
               >> Swap >>
                               Object b;
               << Swap <<
   throw 2;

Here, a needs to be destructed, not b.  If a simple stack is used (that
is, only one exception stack), b would be destroyed, then a.  This
would mess up B's stack.

As a final touch, your threadmain should look something like:

void threadmain() {
  try {
    (*user_thread_main)();
  } catch (...) {
    // User threw an exception in this thread, and didn't handle it.
    unhandled_exception = 1;
    return_code = BAD;
    return;
  }

  // Ok
  return_code = GOOD;
}

That'll catch a stray throw within a thread.

You'll also probably need an exception_state_init and there may be an
exception_state_free routine that you may need to call.

All of these are (typically) internal to the compiler, and you're probably
out of luck if your compiler vendor does not publish these specs.


--
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |http://www3.sympatico.ca/bob.beland/indexn2f.html
_____________________ ____|________     Paul Derbyshire     pderbysh AT usa DOT net
Programmer & Humanist|ICQ: 10423848|