[235] in Pthreads mailing list archive
Re: pthreads and C++
daemon@ATHENA.MIT.EDU (William S. Gribble)
Thu Jan 18 12:09:40 1996
From: "William S. Gribble" <grib@cs.utexas.edu>
Date: Thu, 18 Jan 1996 10:12:36 -0600 (CST)
To: Axel.Hein@informatik.uni-erlangen.de
Cc: pthreads@MIT.EDU
In-Reply-To: <199601181511.QAA15093@faui3b.immd3.informatik.uni-erlangen.de> (message from Axel Hein on Thu, 18 Jan 1996 16:11:48 +0100 (MET))
I use pthreads with c++ every day. There is no problem at all; I don't
know where you heard that.
Now, that's not to say everything is sweetness and light; 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.
There are several ways around this. The way I do it now (because it's simple)
is to wrap pthreads in a class, and have a cooperative quit mechanism
whereby the thread that's being killed gets a chance to exit on its own.
You could also [ugly, I warn ye] require that every object declared as a
local by a thread be descended from class pthread_local (or something like
that) whose constructor makes an entry in a list of un-destructed local
variables. Then a thread cleanup function could walk down that list calling
destructors.
The ``right way,'' I think, which I haven't tried yet, is to have the
thread function call wrapped up in a try(), and push a thread cleanup
handler which throws an exception. This makes sure that any locals in
the thread's stack get their destructors called. I'm not actually
sure where thread cleanup functions get called, so that might not
work. An alternative is to kill the thread with a pthread_kill()
[signal] and have the signal handler throw an exception; however,
I believe that threads do not handle signals when they are in a
blocked state waiting for i/o, mutex, condition variable, etc.
True?
Bill Gribble
