From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bossom, John" To: 'Alexander Terekhov' , pthreads-win32@sources.redhat.com Subject: RE: pthreads VCE: problem with destructor Date: Thu, 20 Dec 2001 08:46:00 -0000 Message-ID: <430F887D415DD1118C2700805F31ECF106B589A6@sota0005.cognos.com> X-SW-Source: 2001/msg00161.html Message-ID: <20011220084600.AqfFt54btVBEHTvWsSEtXpZM7j-DD5s-szRWivuui9U@z> A well respected opinion, indeed, given he (David Butenhof) is the author of "Programming with POSIX Threads". However, this is an opinion.... it is not reality today. And demanding a free, open-source, library that was attempting to provide a portable solution for PTHREADs for win32 developers would lull C++ developers into a false sense of security and will get a very rude shock when/if they port their product to UNIX. As I have already stated, if you base your code on a non-standard implementation "today", then you are asking for trouble if you intended on your code to be portable. Even if you demand this change now, just when do you think you are actually going to get a portable solution that you can actually use and depend upon? I, for one, will not tell my company that we cannot release a product on all platforms because I am waiting for the POSIX and C++ standards committee to comply with my request (then waiting (possibly years) for the OS implementors to adopt the "new" standard) --- I would be out of a job. -----Original Message----- From: Alexander Terekhov [ mailto:TEREKHOV@de.ibm.com ] Sent: December 20, 2001 9:09 AM To: pthreads-win32@sources.redhat.com Subject: Re: pthreads VCE: problem with destructor > Please do not take my comments out of the context. The original text was [...] > 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. OK, just one more try... Consider the following opinion: http://groups.google.com/groups?as_umsgid=3A8D120B.73749CEC%40compaq.com "In any RATIONAL and USEFUL implementation that supports both POSIX threads and C++, there's no different between "calling POSIX cleanup handlers" and "throwing a C++ exception", because thread cancellation and exit, and C++ exceptions, are all instances of an underlying universal platform exception infrastructure. That means that POSIX cleanup handlers will be run when a thrown C++ exception propagates through the frame in which the cleanup handler has been pushed; and C++ object destructors will be run when a local object is active in a frame through which a POSIX cancellation or exit propagates. The same, of course, must be true for any other language with exceptions and handlers. Either the "system" is a "system", or it's a collection of spare parts that happen to have been dumped in the same box. The latter may not explicitly violate any standards, and may even be usable with sufficient effort and restrictions; but that doesn't make it a good idea. System implementors should get this right. Application developers should demand it. The days are long gone when exceptions were some arcane thing that only a few weird and non-mainstream languages supported. For a system to work, exceptions must be integrated into the system's basic calling standard along with issues like register usage and the appearance of stack frames. There's simply no excuse for messing this up, and no excuses should be accepted! /------------------[ David.Butenhof@compaq.com ]------------------\ | Compaq Computer Corporation POSIX Thread Architect | | My book: http://www.awl.com/cseng/titles/0-201-63392-2/ | \-----[ http://home.earthlink.net/~anneart/family/dave.html ]-----/" regards, alexander. This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate, or distribute it; do not open any attachments, delete it immediately from your system and notify the sender by e-mail promptly that you have done so. Thank You.