From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30643 invoked by alias); 20 Dec 2001 11:06:01 -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 30616 invoked from network); 20 Dec 2001 11:05:59 -0000 Received: from unknown (HELO eos.telenet-ops.be) (195.130.132.40) by sources.redhat.com with SMTP; 20 Dec 2001 11:05:59 -0000 Received: from jitterbug (D5E050DF.kabel.telenet.be [213.224.80.223]) by eos.telenet-ops.be (Postfix) with ESMTP id 2F57F201EA for ; Thu, 20 Dec 2001 12:05:58 +0100 (CET) Reply-To: From: "Ignace Saenen" To: Subject: new to pthreads Date: Tue, 13 Mar 2001 14:41:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2001/txt/msg00019.txt.bz2 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 (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 section. 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 non-portable? Cheers, Ignace (sorry Thomas for mailing directly by accident) -----Original Message----- From: pthreads-win32-owner@sources.redhat.com [mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Thomas Pfaff 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( __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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ignace Saenen" To: Subject: new to pthreads Date: Thu, 20 Dec 2001 03:06:00 -0000 Message-ID: X-SW-Source: 2001/msg00157.html Message-ID: <20011220030600.jxY7_AVfsk-ph4lgsRYNqWkMCpDVzpbk6UJUMg7o8_w@z> 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 ( 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 section. 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 non-portable? Cheers, Ignace (sorry Thomas for mailing directly by accident) -----Original Message----- From: pthreads-win32-owner@sources.redhat.com [ mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Thomas Pfaff 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( __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