From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2581 invoked by alias); 20 Dec 2001 12:40:58 -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 2559 invoked from network); 20 Dec 2001 12:40:55 -0000 Received: from unknown (HELO four-d.de) (129.247.190.4) by sources.redhat.com with SMTP; 20 Dec 2001 12:40:55 -0000 Received: (from mail@localhost) by four-d.de (8.9.3/8.9.3) id NAA20583; Thu, 20 Dec 2001 13:40:48 +0100 X-Authentication-Warning: atacama.four-d.de: mail set sender to using -f Received: from sinai.intern.net(192.168.2.4) by atacama.four-d.de via smap (V2.1+anti-relay+anti-spam) id xma020574; Thu, 20 Dec 01 13:40:29 +0100 Received: from algeria.intern.net by intern.net (8.8.5/SMI-SVR4) id NAA17454; Thu, 20 Dec 2001 13:40:28 +0100 (MET) Date: Thu, 22 Mar 2001 11:19:00 -0000 From: Thomas Pfaff To: TEREKHOV@de.ibm.com cc: pthreads-win32@sources.redhat.com Subject: Re: pthreads VCE: problem with destructor Message-ID: X-X-Sender: pfaff@antarctica.intern.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2001/txt/msg00021.txt.bz2 > > 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. Please do not take my comments out of the context. The original text was ***** > 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. ***** I do not wanted the destructors to be run because this is nonportable. Before the setjmp/longjmp code the only working implementation for mingw32 was the c++ one that i disliked. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Pfaff To: TEREKHOV@de.ibm.com Cc: pthreads-win32@sources.redhat.com Subject: Re: pthreads VCE: problem with destructor Date: Thu, 20 Dec 2001 04:40:00 -0000 Message-ID: X-SW-Source: 2001/msg00159.html Message-ID: <20011220044000.EDUkSvKL9u3Us2PGChdoWBpHHCmo5PrR1LzY5TwhL1c@z> > > 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. Please do not take my comments out of the context. The original text was ***** > 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. ***** I do not wanted the destructors to be run because this is nonportable. Before the setjmp/longjmp code the only working implementation for mingw32 was the c++ one that i disliked.