This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]