Re: Exceptions Reentrant?

[Mike Moran <moran at mindspring dot com>]

Martin,

I guess I sometimes confuse the issues ... sorry.
I am interested primarily in thread-safety. In general,
I think of something as beeing thread-safe if "static" or
global variables are not used. This usually means that
execution state is saved on the stack.

It *is* possible to make a kernel/threading architecture
which knows about the code generation of a compiler and
saves and restores the necessary global variables during
thread-switching operations.  I assume that this is what
you mean when you say that this is a matter of "thread-library
adaptation". This seems like a less-than-optimal solution,
and seems to bind a kernel/threading-library to a particular
compiler's code generation implementation. Even if all compilers
generated code to use the same symbols, it still seems like ugly
an ugly tie-in to compiler code generation from a sub-system
(i.e. the kernel) which should not care about such things.

To give you some idea of my interest in this area,  I am an
embedded systems programmer who has used and developed
several real-time kernels.

thanks,
mike

Martin v. Loewis wrote:

> > Is C++ exception handling for the 68k target reentrant / thread-safe?
>
> It seems exception handling in C++ is re-entrant by design: It is
> possible to throw another exception while one is being handled. The
> exact semantics is defined by the standard.
>
> Whether exception handling is thread-safe (i.e. whether simultaneous
> exceptions in multiple threads are supported) is a matter of
> thread-library adaption, not hardware architecture. Since 1.1,
> exception handling is thread-safe on systems with Posix, Solaris, DCE,
> or VxWorks threads, if configured properly.
>