Re: catch(...) and forced unwind

[Jason Merrill <jason at redhat dot com>]

On Fri, 12 Dec 2003 17:42:27 -0500, David Abrahams <dave@boost-consulting.com> wrote:

> Jason Merrill <jason@redhat.com> writes:

>> As a result, the following testcase will abort under the compromise
>> behavior:
>>
>>   #include <pthread.h>
>>   #include <iostream>
>>
>>   void *
>>   tf (void *)
>>   {
>>     while (true)
>>       std::cout << "." << std::flush;
>>     return NULL;
>>   }
>>
>>   int
>>   main (void)
>>   {
>>     pthread_t t;
>>     while (true)
>>       {
>>         if (pthread_create (&t, NULL, tf, NULL))
>>           break;
>>         if (pthread_cancel (t))
>>           break;
>>         if (pthread_join (t, NULL))
>>           break;
>>       }
>>     return 1;
>>   }
>>
>> Clearly, this high-level behavior is wrong.  iostream code should be
>> cancelable.  
>
> I'm going to assume some things of which I have no knowledge:
>
> 1. Thread cancellation doesn't induce an asynchronous C++ exception in
>    the thread.

Correct.

> 2. There is some documentation somewhere which indicates that one of
>    the functions called by tf is a "cancellation point" (i.e. may
>    throw thread cancellation exceptions).  Otherwise, it seems to me,
>    "this high-level behavior" would not be wrong.

Basically, all of the C library I/O functions are cancellation points.

>> If we left out the flush, however, the continue option would never
>> actually cancel because the only cancel point in the loop is guarded
>> by the catch(...) in the string inserter.
>>
>> I believe this is a bug in the library: it thinks it knows what sorts of
>> exceptions it will see and wants to swallow all of them, but it is wrong.
>
> It's definitely not a bug if you're just considering the specification
> you quoted above.  You must have some other criteria for saying it
> is.  Care to share them?

I don't expect writing 'cout << "."' to suppress thread cancellation.
Do you disagree that this is an extremely surprising side-effect?

>> 2) explicitly rethrow cancellation--
>
> That seems to violate the specification you quoted.

I don't think the specification is relevant in this case.  Cancellation
uses the exception handling runtime but is not a normal exception; this is
outside the scope of the current standard.

>> 3) don't catch and swallow all exceptions; changing the catch(...) to
>>    catch(std::exception) would catch all exceptions thrown by other parts
>>    of the library, which AFAIK is what we're trying to accomplish.
>
> That also seems to violate the specification you quoted.

Yes, this would require a change in the standard.

> Either you have to lobby to get the standard changed, live with the
> fact that you're going to break it, or live with the fact that not
> having badbit set will suppress cancellation in some circumstances.  I
> don't think it's honest to "fix" the problem by calling the latter
> behavior a bug if that's what the specifications say to do.

The specifications don't say anything about cancellation.  We're in
extensions-land here, so we get to decide what it means.  We can decide
that cancellation acts just like an exception, or we can decide that it
acts like an exception except when it doesn't.  The standard may provide
guidance about what the best solution might be, but no more than that.

Jason