I'm wondering about the behavior of exceptions in an environment which
supports the asynchronous calling of code which can throw exceptions.
UNIX signal handlers are just an example here.  Suppose that a signal
handler throws an exception.  Will all the destructors get called
properly?

A related question regards the behavior of C++ objects in a multi-threaded
environment.  What happens when a thread of execution calls several levels
deep into functions with automatic objects, and the thread terminates?

Does anybody know if the standard will even address these issues?
--
Kevin J. Hopps   e-mail: kjhopps@mmm.com
3M Company   phone: (612) 737-3300
3M Center, Bldg. 235-3B-16 fax: (612) 737-2700
St. Paul, MN 55144-1000      ** USE kjhopps@mmm.com FOR E-MAIL REPLIES **

In article <hopps.740676904@mmm.com> hopps@yellow.mmm.com (Kevin J Hopps) writes:
>I'm wondering about the behavior of exceptions in an environment which
>supports the asynchronous calling of code which can throw exceptions.
>UNIX signal handlers are just an example here.  Suppose that a signal
>handler throws an exception.  Will all the destructors get called
>properly?
>
>A related question regards the behavior of C++ objects in a multi-threaded
>environment.  What happens when a thread of execution calls several levels
>deep into functions with automatic objects, and the thread terminates?
>
>Does anybody know if the standard will even address these issues?

 The standard has an execution model that refers to
single execution thread only. I believe it is beyond the
scope of the present standardisation effort to consider multiple
threads of execution, concurrency, segmentation, persistence, object requests,
dynamic linkage, or other such interesting issues.

 The committee itself will certainly take these things into
consideration, for example the library group will consider these issues
to some extent so that say multi-thread execution will not be *precluded*.

 But neither will the standard specify what happens in a multi-threading
environment, unless the basic execution model is changed.

 I suspect that any C++ program that relies on threading will be
non-conforming, just as many PC based programs that rely on segmentation
control are non-conforming.

 I would love to consider even *coroutines* (synchonous
stack swapping or the like) might be considered, but that too is
excluded by the execution model, as far as I can tell.

 I think load time linkage, however, may be possible,
that is, it is not exluded that linkage be defered until just before
execution commences. I suspect that dynamic (run-time, 'during execution')
is acceptable if, and only if, it could have somehow been performed
before execution commenced.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <hopps.740676904@mmm.com> hopps@yellow.mmm.com (Kevin J Hopps) writes:
>I'm wondering about the behavior of exceptions in an environment which
>supports the asynchronous calling of code which can throw exceptions.
>UNIX signal handlers are just an example here.  Suppose that a signal
>handler throws an exception.  Will all the destructors get called
>properly?

I asked the x3j16 library group about throwing exceptions out of signal
handlers.  The consensus seemed to be that the majority felt that the
final standard should say that throwing out of a signal handler should
produce undefined behavior... that would mean that your program might
crash and burn if you ever tried it.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

hopps@yellow.mmm.com (Kevin J Hopps) writes:

>I'm wondering about the behavior of exceptions in an environment which
>supports the asynchronous calling of code which can throw exceptions.
>UNIX signal handlers are just an example here.  Suppose that a signal
>handler throws an exception.  Will all the destructors get called
>properly?

While this is not completely settled, it appears that C++ will adopt
unchanged the Standard C model of signals.  In C, there is little
you can portably do inside a signal handler other than set global
flags.  Attempting to do much more than that has undefined results.
The same will (probably) be true for C++.  The interaction of signals
and exceptions will (probably) be unspecified or implementation-defined.
Either way, throwing an exception from a signal handler will not be
reliable.  (But then, not much about signal handling is portable anyway.)


>A related question regards the behavior of C++ objects in a multi-threaded
>environment.  What happens when a thread of execution calls several levels
>deep into functions with automatic objects, and the thread terminates?

I do not expect the C++ standard to address this issue at all.  At
best, the C++ part of the library will be defined so as not to
preclude a multi-thread implementation.  (Parts of the Standard C
library make conforming multi-thread implementations rather difficult.)
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Jun22.163333.477@taumet.com> steve@taumet.com (Steve Clamage) writes:
>hopps@yellow.mmm.com (Kevin J Hopps) writes:
>>A related question regards the behavior of C++ objects in a multi-threaded
>>environment.  What happens when a thread of execution calls several levels
>>deep into functions with automatic objects, and the thread terminates?
>
>I do not expect the C++ standard to address this issue at all.  At
>best, the C++ part of the library will be defined so as not to
>preclude a multi-thread implementation.  (Parts of the Standard C
>library make conforming multi-thread implementations rather difficult.)

I suppose concurrency is a "quality of implementation" issue, but I
sincerely hope that the eventual C++ standard does not preclude
implementations that support concurrency.  I mean the entire standard,
not just the standard library.  Currently many systems provide
user-space support for threads, and OS support is becoming more and
more widespread, especially in distributed systems.  By the time the
standard is completed (1996? 1998?), the use of threads will be even
more commonplace.  Please don't give us a C++ language standard that
will be useless for concurrent programming.

--steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

In article <1993Jun22.163333.477@taumet.com> steve@taumet.com (Steve Clamage) writes:
>hopps@yellow.mmm.com (Kevin J Hopps) writes:
>
>>I'm wondering about the behavior of exceptions in an environment which
>>supports the asynchronous calling of code which can throw exceptions.
>>UNIX signal handlers are just an example here.  Suppose that a signal
>>handler throws an exception.  Will all the destructors get called
>>properly?
>
>While this is not completely settled, it appears that C++ will adopt
>unchanged the Standard C model of signals.  In C, there is little
>you can portably do inside a signal handler other than set global
>flags.  Attempting to do much more than that has undefined results.
>The same will (probably) be true for C++.  The interaction of signals
>and exceptions will (probably) be unspecified or implementation-defined.
>Either way, throwing an exception from a signal handler will not be
>reliable.  (But then, not much about signal handling is portable anyway.)
>
>
>>A related question regards the behavior of C++ objects in a multi-threaded
>>environment.  What happens when a thread of execution calls several levels
>>deep into functions with automatic objects, and the thread terminates?

Good question -- unless something is done, the storage for the
thread's stack, and thus and all those automatic objects, will be
freed, but the objects' destructors won't be called. For this and many
other reasons, it's not really a good idea to go around terminating
threads willy-nilly.

>I do not expect the C++ standard to address this issue at all.  At
>best, the C++ part of the library will be defined so as not to
>preclude a multi-thread implementation.  (Parts of the Standard C
>library make conforming multi-thread implementations rather difficult.)

I second the vote for "not precluding" multi-threaded use. For
instance, the standard C asctime() function returns a pointer to a
static array of characters. This is gratuitiosly non-thread-safe, and
there are a good number of other interfaces to asctime that could have
been designed, but weren't. While any new "standard" C++ libraries
don't have to be made explicitly thread-safe, please don't make them
obviously non-thread-safe.

Incidentially -- one way to handle signals in a multi-threaded program
is to have the signal handler run in a separate thread that calls
sigwait(), which waits for a signal to be delivered before returning.
In this case, the "signal handler" thread is just another thread, so
it's possible to do anything in the signal handler you can do anywhere
else in the program.

    greg



--
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com