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

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-11 20:52:54

Bill,

We all understand (I hope...) that we cannot easily bypass the non-C++
behavior of the underlying thread libraries.

This does not mean that we cannot handle C++ behavior in those threads,
like the mechanism of C++ exceptions, in any way we like. So, what
"force" is in play here, limiting our freedom to make sound decisions
(whatever those might be...)?

You seem to go back to The C++ Standard as your dogma here, which I
consider not to be appropriate. There is a field of choices that do
*not* belong to neither (1) the underlying thread libraries nor (2) The
C++ Standard. So, we are not as forced as you might think... 

In general, your argument is valid, where our C++ program delegates the
flow of control to some 3rd party lib; there we have to depend on the
behavior of that lib, till flow of control comes back to us again. So,
yes, we are indeed in "C++-land", and then in "lib-land" for a while,
and finally return to "C++-land"...

But that argument is not valid when we add threads, since threading
actually produces a mesh of "lib-land" and "C++-land" everywhere.
Everywhere we look, we suddenly have this crossed (implicit) semantics
of the OS-threads and the C++ language. Even though it might sound a bit
too philosophical (or, should I say, whimsical...) for a C++ library
forum, it is important to understand this ubiquitous influence of
threading.

One example of freedom: where should a thread begin to execute,
according to (1) the C++ standard or (2) the underlying thread
libraries? (1) says nothing at all about that and (2) allows us to pass
any valid PC (in most thread libraries I have encountered, at least).
So, here we can make a choice! As is done in Boost.Threads. If one would
take a fundamentalist's approach to The C++ Standard, one might argue
that *any* execution necessarily needs to start in a function 'main',
coercing "program" with "thread" (NOTE: I do *not* favor that coercion).

Another example of freedom: what should happen when an uncaught
exception leaves the (to The C++ Standard) quite arbitrary start
environment? The C++ Standard talk about "program" with an implicit
context at "main", so that is not directly applicable to our design
decision... what about the underlying thread libraries? They, obviously,
say nothing about this specific C++ unwinding of the stack. You see,
another free choice to make!  

So, please manifest the behavior you regard as the most rational and/or
sound and/or logical. You are not as bound as you might think; which is
also evident in your (almost exclusively very sound) design decisions.

Regards,

David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of William Kempf
Sent: Sunday, August 11, 2002 9:09 PM
To: boost_at_[hidden]
Subject: RE: [boost] Re: Re: Re: Threads & Exceptions

>From: "David Bergman" <davidb_at_[hidden]>
>
>Bill,
>
>That was very flexible of you: "I refuse to ..." ;-)

Sorry, but this one isn't really negotiable for so many reasons.

>I hope you see Eric's point that the "single thread" rules, (inherited
>from the C main entry convention) regarding C++ and main, are not
>automatically applicable to the MT C++ we are dealing with.

Not really, and more importantly I don't see how it would be relevant to

using a main() wrapper any way.

>You surely must appreciate the fact that we leave the safe world of C++
>when we add this, OS-specific, thread dimension, i.e., we are not
>dealing with the original semantics of C++, as defined in those 700+
>pages...

Yes, I understand that.  Thus I *have* to abide by the rules of the 
underlying thread library when I can (and as C libraries they are mute
on 
this subject) and by the C++ standard when I can't.

>This does not mean that we should not follow that intention as closely
>as possible, but we should have the right to question certain implicit
>mappings of terms made here, or?

You can question it when you are defining the standard, not when
building a 
library such as Boost.Threads.  There all that you can do is, again, to 
follow the rules of the underlying thread libraries when they are
defined, 
and the standard when they are not.

>I truly hope that this forum will be open for diverse interpretations
of
>how the C++ standard should be applied to MT C++, at least till such a
>standard emerges (in, say, six years).

Only when you can do so, which means the underlying libraries must
define 
the behavior.  If they do not, then I must obey the defined behavior of
the 
language.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost