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



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



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