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

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-08-11 23:26:31

>From: "David Bergman" <davidb_at_[hidden]>
>
>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...)?

The force is simply that we can not do anything but what the underlying 
libraries and the C++ standard allow us to do.  If the behavior you want to 
use is not defined by either of these, then you can not rely on it.  I can 
not expect all (or even any) platforms to behave in a way that allows what's 
being asked here.

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

Careful.  The word "dogma" is a bit strong in this conversation.  And I 
completely disagree that there's any field of choices beyond what the 
underlying libraries or the C++ standard allow.  What's being asked is that 
we rely on some percieved behavior and not on gauranteed behavior.  That way 
lies folly, even if you could make it work, and I'm betting you couldn't in 
any event.

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

Oh, I understand that we are in undefined land in many places.  We're just 
lucky that enough of it is either defined by the standard, or by the 
underlying thread libraries, to allow us a reasonable chance (actually, in 
practice it's a bit more than reasonable) to provide a C++ solution to the 
problem.  In the case of threads passing out of main(), however, we don't 
have enough gaurantees to be able to do what's being asked.

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

Actually, the main thread begins before the entry to main().  And no one has 
"coerced 'program' with 'thread'" here.  In fact, I've explicitly 
illustrated how they are not the same concepts.

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

No, there's no free choice here.  There's no way to hijack the very specific 
requirements of C++ here.  To illustrate, if the C++ compiler can determine 
that an exception is not caught any where, the stack need not even be 
unwound.  An external library can, especially a C library, can not effect 
this standard behavior, and so it's highly likely that in this situation the 
application will simply terminate() well before you could even try and 
hijack the exception.  The only possible way to alter this behavior is to 
catch the exception... and as a library implementation there's no way to do 
this other than wrapping main() (i.e. implementing main() and causing some 
other mechanism to be the user entry point in applications development).  I 
think I've explained why this simply won't work.

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

The behavior I find most rational is to terminate() on uncaught exceptions.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com