Re: C++ Exceptions

["erik.ivanenko" <erik dot ivanenko at utoronto dot ca>]

Mike Stump wrote:

> > Date:         Tue, 11 May 1999 14:03:51 -0700
> > From: "erik.ivanenko" <erik.ivanenko@utoronto.ca>
>
> > Are C++ exceptions "thread safe" in this sense: Can one safely build
> > working try/catch blocks in separate threads for an application that
> > runs on a real-time executive?
>
> Yes.  I'd like to think so.  We are shpping product that does this, we
> use egcs.
>
> > ie. Can catching an exception thrown in one thread affect the
> > call-stack of another thread? ( Assuming the RT exec uses a single
> > call-stack. )
>
> I don't follow exactly what your asking.  The model assumes that each
> thread have its own private stack, and those stacks are not shared
> between threads, except for the data the user may wish to share
> explicitly.  I think if you have gcc/g++ working in a multithreaded
> environment, that this is true, but I wasn't sure given how you worded
> the above.
>

My fault -- the parenthetical remark is totally incorrect.  Of course,
the  multi-threaded model assumes a stack per thread.  In that case,
thread specific exceptions are thread-safe.  I believe that this does
mean however, the ALL exceptions must be thread-specific -- one cannot
create a try/catch block like this "pseudo code" suggests:
try{
    make-a-thread();
}
catch
{
    all exceptions
}

make-a-thread()
{
if ( ! create-and-run-task-with-entry-point=&task)
    throw  "create exception";

}

task()
{
throw "task specific exception";
}

Here, the try catch block can ONLY catch the create exception, it cannot
properly catch the task specific exception -- a limitation due to the
independent call stacks.  Is that so?

> Also, for EH in threaded environments to work, one must port to the
> system.
>

EH has been ported, and a simple test shows it works.... my only concern
is that the image must know all of the try/catch addresses on bootup.
Also in this port, the global CTORS/DTORS tables are examined and the
global CTORS executed during bootup, prior to any thread creation.  This
negates the possibility of downloading a C++  image to the target to run
as a thread that either uses exceptions or introduces an object with
global scope after the target has started.  ( This global object  is
actually thread-local, but syntatically, it would be considered a global
symbol by the compiler, and so it's CTOR must be invoked at bootup.
Sorry, I am getting off-track here....  )

My confusion arose from the attempt to envision a target that would allow
for downloaded C++ threads to run.   This means thread-specific
CTORS/DTORS and EH tables.  I think I can do the thread-specific CTORS
thanks to ELF, but I don't understand how EH works enough to be able to
implement thread-specific EH ( which is the only workable EH anyway! )

> If I didn't seem to answer your questions, could you rephrase your
> questions, more detail will help us answer more accurately

Thanks for the response, it did clear some things up for me.  My interest
is now is in implementing thread-specify EH tables... a topic that is
totally beyond me.

begin:          vcard
fn:             Erik Ivanenko
n:              Ivanenko;Erik
org:            University of Toronto
email;internet: erik.ivanenko@utoronto.ca
title:          Supervisor, Controls Services
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard