[c++-pthreads] Re: FW: RE: Re: I'm Lost

[Alexander Terekhov]

Mark Mitchell <mark at codesourcery.com> wrote:
[...]
> It sounds like we really are close to a solution then; I think everyone
> here would be happy with the re-cancellation thing, and the destructor
> trick

It would not satisfy me. For one. Cancel unaware code should be made
cancel aware with "pthread_cancel (pthread_self ())" added only if/when
it is really needed. I mean stuff like

void oper() throw(int) {
  /**/
  fclose(/*..*/); // doesn't throw; cancel is unexpected -- language
                  // change with mandatory 2-phase EH and intelligent
                  // cancel delivery is required
}

transformed to

void oper() throw(int) {
  /**/
  try {
    fclose(/*..*/); // can throw; cancel IS expected -- catch below
  }
  catch (std::thread_cancel_request const &) {
    /**/
    std::enable_thread_cancel(); // re-enable cancel state
    std::thread_self().cancel(); // re-inject cancel request
    /**/
  }
}

Well, I guess I could live with

  catch (std::thread_cancel_request & tcr) {
    tcr.stop_stupid_stickyness();
  }

but that's somewhat unsatisfying, so to speak.

regards,
alexander.


Mark Mitchell <mark at codesourcery.com> on 09.03.2006 00:15:37

To:    Jason Merrill <jason at redhat.com>
cc:    Wil Evers <wil at bogo.xs4all.nl>, David Abrahams
       <dave at boost-consulting.com>, c++-pthreads at codesourcery.com
Subject:    Re: [c++-pthreads]  Re: FW: RE: Re: I'm Lost


Jason Merrill wrote:

> If you can interrupt cancellation, re-cancellation is implemented
> trivially simply by just having the cancellation exception destructor
> call 'pthread_cancel (pthread_self ())'.  The sticking point is being
> able to abort the cancellation in the first place, which is what Uli has
> been opposed to.

It sounds like we really are close to a solution then; I think everyone
here would be happy with the re-cancellation thing, and the destructor
trick means that there's really no way the thread can permanently
discard the cancellation request, short of things like longjmp -- and,
of course, if the thread is really determined not to go away it can just
hang around anyhow.  So, it seems like this ought to satisfy everyone
from the user-level perspective.

> I don't think he's opposed to catching it, just to doing anything that
> would involve backing out of the cancellation once it's started.

Would the above satisfy him?

--
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713