This is the mail archive of the
mailing list for the pthreas-win32 project.
new to pthreads
- From: "Ignace Saenen" <ignace dot saenen at pandora dot be>
- To: <pthreads-win32 at sources dot redhat dot com>
- Date: Thu, 20 Dec 2001 12:06:26 +0100
- Subject: new to pthreads
- Reply-to: <ignace dot saenen at mailandnews dot com>
I'm new to this list (and new to pthreads) and I see I dropped in a bit late
into this discussion, but with the discussion is still hot I learned that
there are some difficulties involving the _exit and _clean methods with c++
destructor implementations. I downloaded pthreads win this week as I am
interested in a STABLE (specification wise and debug wise) and if possible
also portable thread library for a windows application.
According to DECthread specs
(http://www.openvms.compaq.com:8000/72final/6493/6101pro_031.html), the (or
is it "it's") pthread interface is interoperable with windows thread
functions, is this also the case with MFC code enabled? Compared to the
windows specification, pthread-win code looks pretty complex and domestic,
and seems to lack 'metered sections', which exist in windows allowing to
sync over process and thread boundaries and behaving much like a critical
Ultimately what I would like to write/have is a C++ TThread class based on a
IThread interface that is "portable" in that it can be implemented by a
pthread implementation or native implementation, that has a few
synchronisation possibilities and, most importantly that it has a run method
that I can override. As I see it now, I am able to use pthreads up to a
certain extent for this, keeping my TThread class portable, but the
destructor is problematic when stack unwinding occurs in the threadfunction
on termination conditions like _exit/_cancel, unless the code is
(sorry Thomas for mailing directly by accident)
[mailto:firstname.lastname@example.org]On Behalf Of Thomas
Sent: Thursday, December 20, 2001 10:25 AM
Subject: Re: pthreads VCE: problem with destructor
On Wed, 19 Dec 2001, reentrant wrote:
> Due to the nature of the beast just as the responsibility lies with the
> programmer to design the program to "cleanly" (including running
> ad nauseum) exit when exit() is called, it should also be the
> responsibility of
> the programmer to design a thread to cleanly exit with pthread_exit() or
> pthread_cancel() are called. Just as exit() should not be called in a
> program if dtors are desired to run neither should pthread_exit() from a
> thread. IMHO.
> I would imagine that exit() was chosen not to be modified to account for
> running C++ destructors for about the same reasons that pthread_exit()
> not account for running C++ destructors. Dtors not being called in
> these cases
> is and should be expected behavior.
> Regardless as Mr. Bossom so well has already stated: I certainly
> depend on pthread_exit() or pthread_cancel() allowing destructors to run
> to be
> portable though. Since the primary purpose of this library is to
> portability of programs using pthreads, counting on pthread_exit() or
> pthread_cancel() to work in a non-portable way seems self-defeating.
This is exactly the reason why i have created the setjmp/longjmp version.
There may be bugs in it but i think they could be discovered if more would
> While attempting to allow dtors to be run upon a pthread_exit() or
> pthread_cancel() is certainly a noble goal, it's beyond the scope of the
> pthread library. It's the programmer's responsibility IMHO.
> So, as I hope is obvious by this point :), I am completely in support of
> "nasty hacks" being removed and a clean C interface version of the
> being provided only.
Try the GC stuff and report bugs.
> My two cents,
> --- Ross Johnson <email@example.com> wrote:
> > I sense a rising and ruthless desire to deal with the problem of
> > the exception-based versions of the library. It would certainly
> > be a lot easier if they weren't there, and there are some
> > hacks in pthread.h supporting them that really are nasty.
> > So ... what to do about them?
> > I will firstly put John's warning in the README file
> > and the README.NONPORTABLE file, and on the Web page.
> > Secondly, there is a standard C version of the library courtesy
> > of Thomas Pfaff's contributions. It uses setjmp/longjmp.
> > Does this need to be built differently to work with C++
> > applications (assuming they are written as John suggests they
> > should be)?
No. The only thing you need is to define __CLEANUP_C to avoid the default
handling in pthread.h.
* define defaults for cleanup code
#if !defined( __CLEANUP_SEH ) && !defined( __CLEANUP_CXX ) && !defined(
These defaults have been added to be backward compatible and it is time to
> > I can try putting it through the VCE run of the
> > test suite as soon as I reinstall my corrupted Windows 98 machine.
> > Thirdly, if possible, consider phasing out all but the VC and GC
> > versions of the library (currently the only standard C versions).
> > That is, phase out the VCE, VSE, and GCE versions.
> > Does anyone wan't to jump up and shout - NO!!
> > Ross