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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-08-12 12:20:54

At Monday 2002/08/12 09:44, you wrote:
>----- 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.

I was referring to your example which you claimed couldn't be done 
portably... as I recall it made a thread and pointed the execution address 
&main

if I'm mistaken, I apologize.  My "illegal C++" was an attempt to show what 
"flow" would/could look like (depending on how the thread system treats 
invocation.... "which instruction gets executed next?" the invoker or the 
invokee).

> > 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.

I'm suggesting as strongly as possible that they SHOULD 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.

it's not baseless. you've come to what I believe to be an erroneous 
conclusion from somewhere!  I don't know where you got it.
it's kinda like trying to figure out where the "hippies" got the idea that 
"Stranger in a Strange Land" was their "bible".  I read the book in 
high-school and _never_ would have interpreted it the way they seemed to.

> > 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.

I can see we're both getting somewhat exasperated by this... a more useful 
response would have been
"Better calm down and re-evaluate what 'blah blah (what you *did* say)' 
means".
I'll go re-read the thread and see where I've misunderstood you.

> >  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
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr.      http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"