[296] in Pthreads mailing list archive
Re: pthread_cancel() and c++ destructors
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Sat Mar 16 20:10:50 1996
To: David Brownell <brownell@ix.netcom.com>
Cc: pthreads@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 16 Mar 1996 17:49:26 -0500
In-Reply-To: David Brownell's message of Sat, 16 Mar 1996 10:18:38 -1000
From: David Brownell <brownell@ix.netcom.com>
Date: Sat, 16 Mar 1996 10:18:38 -1000
Sounds fair -- I knew there were optimization problems back then; if I
were using my G++/Linux box more, I'd know this hadn't changed. How
tough will it be to fix the optimizer bugs? I may not want to know!
Beats me. I think it has to do with code getting moved around by the
optimizer such that the exception-data tables would be difficult to
generate. As you say, ideally, the no-exceptions-raised case
shouldn't have any cost, which sort of implies that this code motion
is still done.
Re global variables, lacking kernel support for threads sharing the same
address space, I suspect it could "work" to use global variables if you
did the signal handling correctly. The "good" way to do exceptions is
zero-overhead except when they're thrown: tables of exception data that
get parsed during stack unwinding for exceptions (or cancellation). The
tables are read-only, so don't cause MT problems. I'd thought that was
what MRS intended; perhaps that's not what the code does now.
I think the globals are used for info about the exception raised. In
the no-exceptions-raised case, I don't think they actually get used.
- If pthread_cancel uses the C++ exception cleanup code, then
some interface is needed between the pthread runtime and the
C++ runtime -- private glue, not for portable code to use.
Yup. Or both need to use a common lower-level mechanism provided by
th C compiler as well.
- If an "exception" were thrown, C++ code could catch it and then
continue running. But POSIX stipulates that cancellation means
the thread should go away. And C++ stipulates that lots of code
would need to be modified to declare "throw (..., xcancel)" else
cancellation would cause unexpected() to be called. So, I think
that throwing an exception is probably not the best answer, and
the that "glue" would not check "catch" clauses at all. (The
POSIX cancellation is "like" exceptions and reuses most of the
exception processing machinery ... but it's not C++ exceptions.)
But "POSIX" refers to the C bindings; there *is* no C++ binding
currently, so far as I know, so we're charting a course through new
territory. And the inter-language issues are always hairy. Perhaps
someday there'll be a C++ threads binding spec that describes a
specific type of exception to be used for thread cancellation, or
exceptions that are re-raised by default, or something. Or maybe
it'll specify that an exception isn't used, at least not in a way
visible to C++, so that C++ handlers just don't get invoked.
- Oh yes, why do I like compiler support for pthread_cleanup.
Imagine a stack that has alternating frames of C/C++ code,
each grabbing locks in the correct order. You need to call each
stack frame's "cleanup" code (C "cleanup functions", and for
C++ the destructors) in the right order ... the "glue" needs
to have a deal with several parties, and I don't know of a good
way not to have the compiler be one of those parties.
Yeah, that's the argument for putting the EH code into the gcc back
end. If (and it's still a pretty big "if") we could rely on the use
of gcc, I'd recommend trying the EH cancellation method in MIT
pthreads (once the gcc end of it works).
I suppose it's discussions like this that make folk conclude that threads
really ought to be part of the programming language, so that there aren't
such fuzzy lines between the language's runtime environment and support that
the OS provides to it.
Well, there's the SyncC++ stuff being done in Europe(?) that MRS is
interested in, and I'm hoping to get some time this weekend to get
back to my GNU Concurrent C work. The SyncC++ stuff is further along,
I believe, but GNU Concurrent C will have the advantage that the
extensions are accessible in C as well as C++.
I don't think it really helps with the inter-language issues though.
