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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-12 11:44:53

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, August 12, 2002 10:54 AM
Subject: Re: [boost] Re: Re: Threads & Exceptions

> >>btw, why the heck is it "legal" for you to "start a thread" executing at
> >>main() but NOT legal to "call" main()?
> >>I know, I know, the "standard" says you can't call main(). (as you
report).
> >
> >I don't "start a thread" executing at main, the underlying thread
> >libraries do.  That's well defined behavior in the underlying MT systems,
> >and is part of the C++ language implementation and is thus
> >conforming.  The user calling main(), on the other hand, just produces
> >undefined behavior.
>
> you're just playing word games ("it all depends on what the meaning of is
is")

No, I'm not, and I find that claim a little adversarial.

> I assert that using an "underlying library" to cause main to be executed
> again is NO different than calling it directly!

I never asserted that the "underlying library" caused main to be executed
_again_.  In fact, that's not at all what occurs.

> If you assert that one is legal and the other isn't by the wording in the
> standard, then either the standard is in error, or your interpretation is.

I didn't assert that anything to do with MT was "legal".  I asserted that
the underlying libraries do something documented, and reasonable, as
extensions to the standard.  Calling main() in user code is, however, quite
illegal, and not even provided as an extension by any platform I'm aware of.

> I suspect that, in fact, the standard is silent on at least one of the
above.

But the thread APIs aren't.

> If the standard is silent on a subject (and apparently it's exactly like
> the tar baby with respect to threads) we should be able to choose a
> behavior that isn't wildly at odds with the rest of the standard (i.e.
> causes no real surprises).

Only if the non-standard threading extensions explicitly allow it.

> >>You certainly bandy about the old standard when it suits your purpose
and
> >>I believe you have mis-read it miserably in an attempt to justify a poor
> >>decision on your part (not allowing exceptions to be passed back).
> >
> >Where have I misread it?
>
> I have no idea where you misread it.

Then stop making baseless accusations.

> You seem to think that some clause about uncaught exceptions in main()
> applies to uncaught exceptions in another thread.

I never made that claim.  Better calm down and go back and read what I *did*
say.

>  That you cannot (in all
> cases) detect whether join() will ever be called, apparently leads you to
> believe that it is "safer" to assume (we _all_ know how to parse that
word)
> that it won't be, and include any uncaught exceptions in a thread in the
> set of "uncaught exceptions in main()".  Therefore the program will be
> terminated.

You can't detect whether join() will ever be called in *any* cases, but
other than that, yes, you've captured what I believe here.  However, you've
offered no technically based counterpoint to this.

> You correctly assert that "asynchronous exceptions" canNOT be handled (I
> further assert that asynchronous _anythings_ canNOT be handled in C++....
> there aren't any constructs for doing it), but apparently are going to
come
> up with some way to synchronize the program termination.  If you think
that
> async exceptions are a pain...wait 'til you consider async program
termination.

Apples and oranges, and if you really think about the two I don't think
you'd come to the conclusion that async termination is in any way more
problematic then synchronous termination, much less than async exceptions.

Bill Kempf