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

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

At Tuesday 2002/08/13 08:02, you wrote:
>----- Original Message -----
>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.

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

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

> > >   You could reword what you just said as an opinion, and I
> > >wouldn't object (though I'd still ask you to do the leg work to prove me
> > >wrong), but as it is you're not stating opinions but accusing me of
> > >something you can't prove.  That's a baseless accusation.
> >
> > Ok, it is my opinion that there is nothing in the standard (that has been
> > presented thus far) that would preclude implementing the separation of
>call
> > and return to/from a function via a thread mechanism, and that furthermore
> > exceptions _could_ be passed back when the return from the function was
> > instantiated.
>
>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.

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