This is the mail archive of the mailing list for the pthreas-win32 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]

new to pthreads

Hi everyone,

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
(, 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)

-----Original Message-----
[]On Behalf Of Thomas
Sent: Thursday, December 20, 2001 10:25 AM
To: Pthreads-Win32@Sources.Redhat.Com
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
> destructors,
> 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
> C++
> 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()
> should
> 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
> wouldn't
> depend on pthread_exit() or pthread_cancel() allowing destructors to run
> to be
> portable though.  Since the primary purpose of this library is to
> enhance
> 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
using it.

> 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
> the
> "nasty hacks" being removed and a clean C interface version of the
> library
> being provided only.

Try the GC stuff and report bugs.

> My two cents,
> Dave
> --- Ross Johnson <> 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(

#if defined(_MSC_VER)
#define __CLEANUP_SEH
#elif defined(__cplusplus)
#define __CLEANUP_CXX
#define __CLEANUP_C


These defaults have been added to be backward compatible and it is time to
remove them.

> > 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
> >


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