[c++-pthreads] Re: pthread_cancel and EH: let's try this again
Jason Merrill
jason at redhat.com
Wed Jul 13 16:56:59 UTC 2005
On Wed, 13 Jul 2005 11:40:45 -0400, David Abrahams <dave at boost-consulting.com> wrote:
> Jason Merrill <jason at redhat.com> writes:
>>> 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.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111548
We've gotten other private bug reports, too. Unfortunately, that bug
report got marginalized because the reporter used async cancel in his
reduced testcase...I would guess that the original code doesn't, but I
haven't looked yet.
I'm sorry, my example above is misleading; in other the bug report that
motivated me to bring this up again there is no recover(), just
catch(...){}. All the recovery has been done by registered cleanups, the
above loop is just there to keep the thread alive. Which it shouldn't in
the case of cancellation.
Jason
More information about the c++-pthreads
mailing list