This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [basic-improvements] try/finally support for c/c++ - more tests

--On Thursday, November 07, 2002 12:18:33 PM -0800 Geoff Keating <> wrote:

Mark Mitchell <> writes:

We're trying to implement one particular piece of functionality required
by the POSIX threads interface; namely "pthread_cleanup_push" and
friends. (I know that any feature might get used more widely, but this
is the motivation, as I understand it.)  Furthermore, we're trying to
make the POSIX threads cleanups play nice with exception-handling.
Yes, this is right, but your example is not the case we really care
about.  What we particularly want to make work is this C++ code:

struct A { ~A() { ... } };

  A foo;
  sigpause ();  // cancellation point, I hope

Here, if 'sigpause' gets cancelled, we want A's destructor to not be
I think you mean you want it *to* be run?

These kinds of cases are easily handled by my #ifdef __cplusplus idea
for the pthread_cleanup_push definition.

As far as I can tell, the only reason to add anything to the compiler
(whether it be try/finally or __builtin_pthread_cleanup_push, or
whatever) is to make it possible to write C code that is linked with
C++ programs, and have exceptions unwinding through the C code run
the cleanups.

Note that this can only happen if the C code calls C++ code, either
explicitly or through a function pointer.  In which case it has to
worry about exceptions already, whether they come from cancellation
or an exlicit throw.  I'm confused.

Mark Mitchell      
CodeSourcery, LLC  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]