Re: [boost] Re: first sight

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-17 00:57:16

----- Original Message -----
From: "Lee Brown" <lee_at_[hidden]>

> What about being stuck on exceptions? A lot of C++
> programmers do not use exceptions, because they increase code size
> dramatically.

Not on all compilers. Try CodeWarrior, for example.

> Are we to think they shouldn't have access to a C++ API for
> thread cancelation?

At boost we are writing libraries for Standard C++, and though we account
for poor-quality implementations, we try not to limit our designs because of
them. As for other options, in general there is /no/ other way to acheive
thread cancellation in C++ without invoking undefined behavior.

> Furthermore....
>
> I believe, throw is like setting "errno" and then using a "goto"
statement.

In what sense? Yes, it is an error-reporting mechanism that involves
transfer of control, but I can think of many ways in which it is not like
that:

1. goto can only transfer control within a single function; throw crosses
function boundaries
2. errno is a global variable, thus vulnerable to modification by other
threads before the error is handled; an implementation of EH designed with
threads in mind is not.
3. exceptions can carry more information than an errno, and are infinitely
extensible
4. if an exception is thrown during construction of an object, the object
never comes into existence. There is no danger of half-constructed objects
with broken invariants lying around. Goto can't do that
5. Using exceptions can be much more-efficient than checking errno, since
the compiler doesn't have to add checks to the non-error code path.

>
> If this is true, the "C++ stack"  is actually the lowly "goto" statement.

Well, no, the C++ stack is a data structure, whereas the goto statement...
is a statement.

> i.e.
>
> some_func() {
>    Widget m;
>
>    if (true) throw 1;
>
>    m=2;
> }
>
> is equivalent to:
>
> some_func() {
>     struct c_widget m;
>     c_widget_init(&m);
>
>     if(true) {
> errno = 1;
>             goto cleanup1;
>      }
>
>     m=2;
>
>   cleanup 1 :
>         c_widget_exit(&m);
> }
>

No, control does not neccessarily proceed directly to some_func's caller in
the first case.

Perhaps you're trying to translate the C++ version at the top into some kind
of 'C' intermediate language, like an EDG front-end? Then the compiler would
have compiled in a check of errno immediately after each function call. If
so, what's your point?

> A thread can be canceled in the middle of a throw.

Not with any of the schemes we've been discussing for use with exceptions. A
cancellation request can be posted to a thread, but it won't die until the
exception completely unwinds.

> Yes, the code they call saves us
> a lot of trouble but it is code that may never be executed.

So you would leave out all error-handling code? If all goes well that will
never be executed.

> In a cancel  enabled envirionment we can not use goto statements to
restore
> resources, we must use cancel_push and cancel_pop.

Why do you say that?

> It seems to me POSIX threads are correct. If cancelation is to be
implemented
> it would probably be wise to move towards their model with a more handsome
> and convenient API.

Are you proposing that cancel_push, cancel_pop, goto statements with
explicit cleanups, and a ban on objects with destructors on the stack is
more handsome and convenient than using exceptions**, or have I misread you?

> This API would also assist in covering up any ugly
> implementations details imposed by less sophisticated platforms.

What did you have in mind?

-Dave

**I have seen schemes like that; they're nightmarish. Ask anyone who's
programming for EPOC, if they still have any marbles left.