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

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-08-13 16:01:46

At Tuesday 2002/08/13 12:37, you wrote:
>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > At Tuesday 2002/08/13 08:02, you wrote:
> > >From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > > > At Monday 2002/08/12 11:48, you wrote:
> > >[deleted]
> > > > I'm not sure that language support is all that's needed.  Tho I really
> > >wish
> > > > _some_ HLL would get around to having a swap operator (declaring it
> > >needing
> > > > to be atomic would be ++good) it might even be sufficient.
> > >
> > >I don't follow your thinking here, but I get the feeling you don't
> > >comprehend the issue.
> >
> > The only language deficiency I see (and it's a show stopper) is the lack
>of
> > a way to specify an atomic set/test.
> > Since an atomic set/test is necessary for synchronization, and an atomic
> > swap can be used as a set/test, I was just commenting that its inclusion
> > may suffice to solve the problem.
>
>Again, I don't understand your thinking.  I don't see how the issue at hand
>(unhandled exceptions in the main thread resulting in terminate() being
>called, possibly with out thread unwinding) can be solved by a set/test,
>atomic or not.  I also don't see how synchronization plays a part here
>either.

The ONLY complaint I've heard you voice is "race condition"... later you 
mentioned "without language support"
This may not directly bear on something _I_ never considered a problem in 
the first place...attempting to propagate an exception out of the "main 
program".  I thought it bore on your worries about polling and "race 
condition".

> > > > as an aside, I _detest_ coding to the "lowest common denominator"
>which we
> > > > appear to "have" to do.
> > >
> > >It's not a "lowest common denominator" issue.  The problem at hand here
>is
> > >undefined by ALL the APIs, as well as the C++ standard.
> >
> > And we're refraining from defining something because we fear that the
> > "Gazorninplatz IV" compiler/library won't be able to what we specify.  For
> > reasons I don't understand, "lowest common denominator" seems to be the
> > idiom when in fact we should be saying "greatest common denominator".
>
>I believe a large majority of compilers will prevent us from solving the
>issue, regardless of what's defined or undefined behavior.  That aside,
>though, I still don't think you can claim this to be a "lowest common
>denominator" idiom, since it's undefined behavior on ALL platforms.

I infer that "it's" means un handled exceptions in the main thread (I say 
again, something that I've not been considering)

>[deleted]
> > >And this is what I think clinches that you don't understand the issue at
> > >hand.  I never claimed there was anything that precluded the separation
>of
> > >call and return to/from a function via a thread mechanism.  Or that
> > >exceptions could be passed back when the return from the function was
> > >instantiated.  I claimed that the concept could not be applied _to the
>main
> > >thread_, because that results in an explicit call to terminate(),
>possibly
> > >with out stack unwinding, no less.
> >
> > Since it is _illegal_ for a user to "call" main() (thanks for pointing
>that
> > out, tho I'm puzzled at the committee's thinking here), I don't see why
> > this is relevant.
>
>Because of the defined behavior of thread_exit().

ok, this sounds like another giant misunderstanding.
if an exception is thrown in the "main thread" and it is uncaught, do 
whatever you wish.
I don't care.
I've never cared (well, formatting my primary drive would irk me a lot).
That never was the point of the discussion (from MY pov anyway... another 
misunderstanding we appeared to have).
The only reason I got into the discussion was I perceived you to say that 
an "uncaught exception" from ANY thread was best handled by termination of 
the program (again, probably something I mis-inferred).
That's it.
That's all I want to stop.

What I want to _continue_ is an agreement that _some_ mechanism for 
allowing exceptions to be passed (via join() if that's how one retrieves 
status about a thread) in addition to (instead of?) some "return value".
It would disappoint me if I had to alter a function in order to implement a 
"delayed call" or whatever term we're going to use to describe this feature.
It's also obvious (to me) that we canNOT possibly pass all possible 
exceptions, I suggested a set, and volunteered to assist in writing the code.

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