From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Alexander Terekhov" To: pthreads-win32@sources.redhat.com Subject: Re: pthreads VCE: problem with destructor Date: Thu, 20 Dec 2001 02:35:00 -0000 Message-ID: X-SW-Source: 2001/msg00156.html Message-ID: <20011220023500.DrvzmWmG_1Ty1HLMBHpkIi8PQqLo5qkbCa8aUU1ePVc@z> >> 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 @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" 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 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