This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
Re: pthreads VCE: problem with destructor
- From: "Alexander Terekhov" <TEREKHOV at de dot ibm dot com>
- To: pthreads-win32 at sources dot redhat dot com
- Date: Thu, 20 Dec 2001 11:36:12 +0100
- Subject: Re: pthreads VCE: problem with destructor
>> 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.
Well, you are certainly allowed NOT to use pthread_exit()
and pthread_cancel() in your C++ programs. As long as
implementation invokes C thread cleanup handlers *IN C*
programs IT IS CONFORMING.
Why do you care how pthread library for C++ implements
it wrt to C++ stack unwinding? As long as you are not
using it (_cancel/_exit) that should not be an issue
for you.
> This is exactly the reason why i have created the
> setjmp/longjmp version.
I am really puzzled. Since there is no standard
PTHREAD C++ bindings that would guarantee things
such as C++ tack unwinding on thread exit/
cancellation, any C++ threaded written to exploit
such things is NOT truly portable. However, there
is practically no way to make thread cancellation/
exit work in C++ programs using setjmp/longjmp
because the C++ standard restricts the LEGAL
usage of longjmp in *C++* programs:
ISO/IEC 14882:1998(E), Pg 347:
"The function signature longjmp(jmp_buf jbuf, int val)
has more restricted behavior in this International
Standard. If any automatic objects would be destroyed
by a thrown exception transferring control to another
(destination) point in the program, then a call to
longjmp( jbuf, val) at the throw point that transfers
control to the same (destination) point has
undefined behavior."
^^^^^^^^^^^^^^^^^^
regards,
alexander.
Thomas Pfaff <tpfaff@gmx.net>@sources.redhat.com on 12/20/2001 10:25:14 AM
Sent by: pthreads-win32-owner@sources.redhat.com
To: "Pthreads-Win32@Sources.Redhat.Com"
<pthreads-win32@sources.redhat.com>
cc:
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 <rpj@ise.canberra.edu.au> 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(
__CLEANUP_C )
#if defined(_MSC_VER)
#define __CLEANUP_SEH
#elif defined(__cplusplus)
#define __CLEANUP_CXX
#else
#define __CLEANUP_C
#endif
#endif
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
> >
>
Regards,
Thomas