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

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

At Monday 2002/08/12 05:18, you wrote:
>>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
>>>I'm not sure what you were trying to illustrate with this code... but 
>>>the use of illegal C++ would seem to make anything you observe irrelavant.
>>
>>that you do NOT want to implement any form of exception passing across 
>>thread boundaries is pellucidly clear.
>>Why don't you just say "I don't want to...and I wont!" and  let it go at 
>>that.  Then we can all save some time.
>
>Because, as in the past, it is possibly someone will find a killer 
>argument to change my mind.
>
>>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")

I assert that using an "underlying library" to cause main to be executed 
again is NO different than calling it directly!
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 suspect that, in fact, the standard is silent on at least one of the above.
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).

>>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.
You seem to think that some clause about uncaught exceptions in main() 
applies to uncaught exceptions in another thread.  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 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.

>Bill Kempf
>williamkempf_at_[hidden]

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"