[239] in Pthreads mailing list archive
Re: pthreads and C++
daemon@ATHENA.MIT.EDU (David Brownell)
Fri Jan 19 19:59:02 1996
Date: Fri, 19 Jan 1996 10:19:40 -0800
From: David Brownell <brownell@ix.netcom.com>
To: "William S. Gribble" <grib@cs.utexas.edu>
Cc: Axel.Hein@informatik.uni-erlangen.de, pthreads@MIT.EDU
Hmm, I also use pthreads with C++ (almost :-) every day ... though
I'll have to confess, not with the GCC/MIT-PTHREADS combo. I'll take
your word for it that basic functionality works fine. However, on
Solaris 2.5 I know that they've been integrated in a way that doesn't
sound much like you were talking about:
- The C++ runtime library "terminate" and "unexpected" handlers
are thread-specific.
- The iostream interface got extended with locking primitives
so you can stop worrying about two streams interleaving input
or output operations. (This is the tip of the iceberg with
respect to making libraries be MT-safe! But getting terminate
handlers etc to be TSD, plus iostream support, covers most of
what folk care about. Me, I don't use iostreams.)
- pthread_cancel() of a thread causes destructors for automatic
objects to be invoked before that thread disappears.
- For threads with mixed C and C++ stack frames, the C "cleanup
functions" (as specified in the POSIX.1c C binding) and the
C++ "automatic object destructors" are called in the correct
order, interleaved etc. (So for example the destructors can
be relied on to release locks in the right order, no deadlocks
get created by your programming environment.)
I'm not totally "up" on the latest pthreads and g++ environment,
but think that work isn't quite that far yet. I've talked to some
folk about this, but haven't made any time for it yet. (Someone
please post me the ftp address for the latest pthreads, please?
My Linux box is alive again now!)
I'm concerned about this suggested feature:
William S. Gribble wrote:
>
> ... there's still the
> issue of objects with destructors being declared as local variables
> in a thread function. You have to ensure that the destructors get
> called when the thread is killed.
Doing this for "kill" (signal) handling seems, ah, "unhealthy". It'd
complicate things a lot ... why should a kill causing an exit behave
differently in a single threaded case (no 'auto' destructors called)
and a multithreaded case (they _would_ get called)? Seems bug-prone.
Maybe by "kill" you didn't mean "pthread_kill", but "pthread_cancel".
Then I'd agree that those destructors should get called. Application
level workarounds for the lack of cancellation support do seem like
they'd be possible (you mentioned one good one: wrap your C++ threads
in a class that has some cancellation-like mechanism based on alerting
threads to their pending demise), but I think that implementing it to
really be compatible with POSIX.1c and ANSI-C++ is more involved.
- Dave
p.s. My preferred implementation for "cancellation calls auto destructors"
involves an extension to the G++ runtime code which traverses
the stack for exception processing. It'd just call destructors,
not "catch" clauses. There's evidently a minor change to the
code generator that'd be involved. The PThreads runtime library
support for cancellation would call the G++ runtime code to
unwind one stack frame at a time (by calling its destructors),
and the implementation of cancellation cleanup handlers for C
programs would be made similarly compatible with C++.
