This is the mail archive of the
mailing list for the pthreas-win32 project.
RE: pthreads VCE: problem with destructor
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- To: 'Alexander Terekhov' <TEREKHOV at de dot ibm dot com>, pthreads-win32 at sources dot redhat dot com
- Date: Thu, 20 Dec 2001 11:44:21 -0500
- Subject: RE: pthreads VCE: problem with destructor
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
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.
From: Alexander Terekhov [mailto:TEREKHOV@de.ibm.com]
Sent: December 20, 2001 9:09 AM
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:
"In any RATIONAL and USEFUL implementation that supports both POSIX threads
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
infrastructure. That means that POSIX cleanup handlers will be run when a
thrown C++ exception propagates through the frame in which the cleanup
has been pushed; and C++ object destructors will be run when a local
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
Either the "system" is a "system", or it's a collection of spare parts
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
only a few weird and non-mainstream languages supported. For a system to
exceptions must be integrated into the system's basic calling standard
with issues like register usage and the appearance of stack frames.
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 ]-----/"
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.