RE: [boost] Re: Re: Re: Threads & Exceptions

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-08 21:17:39

It is a good thing that someone (Darryl) dares to question the validity
of applying the wordings of a mono-thread standard to this context. It
seems that we have quite some flexibility here, since the multithreaded
programs are not "C++ applications" in the strictest sense of the word,
since the C++ semantics assume sequential execution, or am I totally
wrong here (i.e., need to go back and read those 700+ pages again)?

WARNING: The following paragraph is not to be taken 100% seriously.

One way to apply the C++ semantics to these multi-threaded "real"
programs would be to add a meta layer consisting of a thread scheduler
(i.e., add our own "green threads") and either (a) a C++ interpreter or
(b) enforcing yield operations, and watch the C++ semantics act on such
a combined program. The resulting behavior, after proper abstraction of
the meta constructs, could be the extended procedural semantics for our
multi-threaded programs, or "MT-C++".

I totally agree that the procedural semantics should resemble that of
the C++ standard as much as possible, but the freedom of interpretation
(i.e., the variety of possible mappings of the mono-threaded semantics
to the multi-threaded "reality") should be acknowledged. Thus, the
question whether something "complies" should be open for (a creative)
discussion.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Thursday, August 08, 2002 11:05 AM
To: boost_at_[hidden]
Subject: [boost] Re: Re: Re: Threads & Exceptions

In a single threaded environment, there is only one thread to terminate,
so
yes, it is obvious. In a multi-threaded environment, none or maybe a
select
few of the threads might need to terminate when a thread has an uncaught
exception. Communicating which threads should be terminated is one
difficult
task. Another is learning and understanding this completely different
paradigm where the relationship between threads has to be explicit. I'm
all
for it though, because almost any non-trivial application uses threads.

Maybe the problem is there are few high-level multi-threading concepts,
if
any. Most things are low-level like mutexes and threads. If there was a
better way to describe the synchronicity of a system, the compiler could
even generate the thread_terimate ()s, etc.

----- Original Message -----
From: Darryl Green
Newsgroups: gmane.comp.lib.boost.devel
Sent: Wednesday, 2002:August:07 8:30 PM
Subject: RE: Re: Re: Threads & Exceptions

I'm a little bemused by the way that some parts of a standard which
afaik
doesn't consider multi-threading at all, seems to be exerting
considerable
influence on what is the "right" way to deal with an uncaught exception
in a
thread. I'm thinking specifically here of the "uncaught exception calls
terminate()" behaviour. The logic that leads to this decision appears
obvious in a single threaded environment. The process terminates and if
anything bothers to check/cares the way the process terminated can be
determined (to the extent that the process terminated abnormally, and
maybe
more than this if a handler was installed to report something more).
It seems to me (and maybe this is misguided, but I'd really like to know
where I've gone wrong with this) that once one introduces threads each
thread should be considered as though it were an independent process
that
just happens to have inherited an awful lot of its parents resources
(ie.
all of them) and shares its address space. But what is the per-thread
"terminate()" behaviour? I don't know/it depends/I think it would be
productive to discuss this. I'm not currently buying the "because the
standard says" argument as being terribly valid here, but I'm no expert
-
maybe you can explain why this isn't an area where a more "liberal
interpretation" is appropriate. I don't see a huge amount of difference
between one thread be able to check what led to the thread terminating
(if
one cares) or ignore it, just as is the case for the process parent when
an
process terminates due to an uncaught exception.

Regards
Darryl Green.

> -----Original Message-----
> From: William E. Kempf [mailto:williamkempf_at_[hidden]]
> Sent: Thursday, 8 August 2002 12:35 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Threads & Exceptions
>
>
> ----- Original Message -----
> From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Wednesday, August 07, 2002 4:39 AM
> Subject: Re: [boost] Re: Re: Threads & Exceptions
>
>
> > At Tuesday 2002/08/06 09:37, you wrote:
> > >From: "William E. Kempf" <williamkempf_at_[hidden]>
> > >[deleted]
> > >terminate() is invoked when there is no matching exception
> handler. If
> > >join() magically transports exceptions across thread
> boundaries, the
> > >exception thrown in main() will be caught by the join()ing
> thread, and
> > >things are fine and dandy.
> > >
> > >Unfortunately, when there is no join(), the uncaught exception must
> > >terminate the process, but we don't know in advance
> whether there will be
> a
> > >join() sometimes in the future!
> >
> > I see an "unreported exception" just like any other resource leak.
> > we don't terminate processes because somebody forgets to do
> a delete[]
> > what's so "magic" about an exception?
>
> The C++ standard explicitly defines the behavior here.  I
> suppose that's the
> "magic" you're referring to.
>
> Bill Kempf
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost