From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9365 invoked by alias); 19 Dec 2001 18:22:14 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 9343 invoked from network); 19 Dec 2001 18:22:13 -0000 Received: from unknown (HELO web12305.mail.yahoo.com) (216.136.173.103) by sources.redhat.com with SMTP; 19 Dec 2001 18:22:13 -0000 Message-ID: <20011219182213.90907.qmail@web12305.mail.yahoo.com> Received: from [24.93.48.86] by web12305.mail.yahoo.com via HTTP; Wed, 19 Dec 2001 10:22:13 PST Date: Wed, 24 Jan 2001 14:02:00 -0000 From: reentrant Subject: Re: pthreads VCE: problem with destructor To: "Pthreads-Win32@Sources.Redhat.Com" In-Reply-To: <3C207C17.42CE925C@ise.canberra.edu.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001/txt/msg00013.txt.bz2 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. Simple sample programs included in the distribution of pthreads to demonstrate the technique might help. Maybe something like: class AppExit { public: AppExit( int status ) : m_status( status ) {} ~AppExit( void ) {} int GetStatus( void ) const { return m_status; } private: int m_status; }; void function( void ) { // blah blah blah if( true ) { // Error. blah blah blah failed. throw AppExit( 3 ); } // blah blah blah succeeded, // continue execution as usual... } int main( void ) { try { // Call functions and what not. // If an abrupt exit is required // throw AppExit to unwind the stack // and exit in the catch block. function( ); } catch( const AppExit& ae ) { // App requested to exit. // exit() itself not used here so // global and other dtors will run // correctly. return ae.GetStatus( ); } return 0; } Replace "AppExit" with something like "ThreadExit" and "main" with the name of the thread entry point function, account for the return value type difference and there's an example for cleanly exiting a thread (I'm confident the similar parallel can be figured out without explicitly spelling it out :). I'm not even going to attempt to touch the complexities or nuances of issues related to clean cancellation in any language or on any OS :). I'd instead recommend against cancellation altogether and recommend using a mechanism to signal the thread to exit itself (like throwing an exception above or something). But that's another story and just an opinion. Cancellation is covered in plenty depth elsewhere. 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. 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)? 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 > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: reentrant To: "Pthreads-Win32@Sources.Redhat.Com" Subject: Re: pthreads VCE: problem with destructor Date: Wed, 19 Dec 2001 10:22:00 -0000 Message-ID: <20011219182213.90907.qmail@web12305.mail.yahoo.com> References: <3C207C17.42CE925C@ise.canberra.edu.au> X-SW-Source: 2001/msg00151.html Message-ID: <20011219102200.m8WiqvbDjCwUAt_RBrPO-YRjLxIdGNcnHfrjP6NuoA4@z> 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. Simple sample programs included in the distribution of pthreads to demonstrate the technique might help. Maybe something like: class AppExit { public: AppExit( int status ) : m_status( status ) {} ~AppExit( void ) {} int GetStatus( void ) const { return m_status; } private: int m_status; }; void function( void ) { // blah blah blah if( true ) { // Error. blah blah blah failed. throw AppExit( 3 ); } // blah blah blah succeeded, // continue execution as usual... } int main( void ) { try { // Call functions and what not. // If an abrupt exit is required // throw AppExit to unwind the stack // and exit in the catch block. function( ); } catch( const AppExit& ae ) { // App requested to exit. // exit() itself not used here so // global and other dtors will run // correctly. return ae.GetStatus( ); } return 0; } Replace "AppExit" with something like "ThreadExit" and "main" with the name of the thread entry point function, account for the return value type difference and there's an example for cleanly exiting a thread (I'm confident the similar parallel can be figured out without explicitly spelling it out :). I'm not even going to attempt to touch the complexities or nuances of issues related to clean cancellation in any language or on any OS :). I'd instead recommend against cancellation altogether and recommend using a mechanism to signal the thread to exit itself (like throwing an exception above or something). But that's another story and just an opinion. Cancellation is covered in plenty depth elsewhere. 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. 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)? 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 > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com