[c++-pthreads] Re: pthread_cancel and EH: let's try this again

[Jason Merrill]

On Tue, 12 Jul 2005 20:07:55 -0400, David Abrahams <dave at boost-consulting.com> wrote:

> Jason Merrill <jason at redhat.com> writes:
>
>> OK, let me clarify my position.  For a new C++ threading library, I would
>> continue to prefer scheme #1.  But this isn't a new library, it's an
>> extension of an existing library.
>>
>> The main benefit of scheme #2 is that existing pthread_cancel-safe C++ code
>> written to use pthread_cleanup_push/pop continues to work.  
>
> What do you mean by "work?"  Can you explain the issues here, and show
> just what would be broken by scheme #1?

Thread robustness code like the following:

while (true)
 try
  {
   body();
  }
 catch (...)
  {
   recover();
  }

Under the old non-EH implementation this thread cancelled properly.  Under
#1 it doesn't; it goes into an infinite loop of throw/recover.

>> if someone specifically told the thread to go away, they don't want it
>> to recover, they want it to go away.  The thread doesn't get to
>> second-guess that request, it has to go away.  It can take arbitrarily
>> long to get around to actually going away, but it can't actually decide
>> not to.  It especially can't decide this implicitly, as a side-effect of
>> code written to handle exceptions.
>
> As Alexander says, a thread can always disable cancellation and never
> re-enable it.  AFAICT, the idea that we can somehow force a thread to
> cancel via a synchronous notification is just a myth.  I don't think
> we can make any sensible decisions until face reality.

Sure, a thread can disable cancellation.  I consider that "taking
arbitrarily long," because if it ever enables it again the request is still
there and will be acted on.

Furthermore, if you find that your cancel isn't being processed, it's easy
enough to grep for pthread_setcancelstate.  Finding the random code written
to deal with program-generated exceptions which is now interfering with
cancellation is not as simple.

Incidentally, my list of uses of catch(...) omitted the use in iostreams,
which is much like the inter-language glue case, except that it's just glue
to another error reporting mechanism.  As in that case, #1 handles the
iostream use by re-asserting cancel later on.  #2 handles it by just
continuing to run cleanups if the function is allowed to throw, or by
disabling cancellation within the function if it isn't allowed to throw.
#3 blows up.

Jason