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

[David Abrahams]

Jason Merrill <jason at redhat.com> writes:

> On Tue, 12 Jul 2005 20:07:55 -0400, David Abrahams <dave at boost-consulting.com> wrote:
>
>> Jason Merrill <jason at redhat.com> writes:
>>
>>> 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.

The only places I've seen code like that, you absolutely need
recover() to execute, even if the next thing you're going to do is
terminate, or terminate the thread.  Otherwise, you end up with
corrupted or lost data.  In those cases, there is absolutely no
advantage to being able to stop the thread and have all the
destructors execute but not execute the catch(...) block.  

Do you have a counterexample?  I'm not sure I would be convinced by
one, but at least one counterexample is definitely a prerequisite for
me to be convinced.

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

As someone else has said, there's no practical difference between
"arbitrarily long" and "never."

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

You have a point, but I consider it a very weak argument.  Most
programs don't have many catch(...) blocks, and it's usually pretty
easy to see whether they are going to rethrow.

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

Right, now I remember.  I guess that makes the "re-asserting cancel"
idea somewhat more compelling.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com