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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-08-13 14:37:15

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.

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

> > > >If you can define what's erroneous, let alone how it's erroneous,
then
> >the
> > > >accusation is baseless.  Believing I'm wrong is not the same thing as
> > > >proving I'm wrong.
> > >
> > > no kidding.... OJ isn't in jail.
> >
> >You're being a little adversarial again.  Work with me, not against me.
>
> You've got me quite puzzled here.  I have no idea how you misinterpreted a
> statement that is equivalent to "I absolutely agree" into something that
> appears adversarial.

Probably because of differences in opinions involved with OJ.  Let's just
drop this, as it's off topic.

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

Bill Kempf