|
Boost : |
From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-09-27 11:37:01
Fredrik Blomqvist wrote:
[...]
> > vector1.push_back(e1);
> > try {
> > vector2.push_back(e2):
> > }
> > catch(...) {
> > vector1.pop_back();
> > throw;
> > }
>
> Isn't this a good example of something scopeguard ...
would also solve... but >>NOT<< having any nasty portability
problems [and that's just one reason among a couple of others
to avoid catch(...)-like-above thing] with respect to "safety"
of thread cancel and thread exit under currently-quite-common-
threaded-C++-approach known as "forced unwinding"-Y'know-
"catch(...)-doesn't-exist" that, unfortunately, IS used by
numerous C++ implementations out there... like the following
one: <for example>
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/EDCLB130/3.522.14
("3.522.14 pthread_cancel() -- Cancel a Thread")
http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/EDCLB130/3.522.30
("3.522.30 pthread_exit() -- Exit a Thread")
"....
Standards / Extensions C or C++ Dependencies
POSIX.4a both POSIX(ON)
....
Special Behavior for C++
Destructors for automatic objects on the stack will
be run when a thread is canceled. The stack is unwound
and the destructors are run in reverse order. "
<?>
regards,
alexander.
-- http://groups.google.com/groups?selm=3D89CACB.12BB6122%40web.de ("action_on_propagation_of(...) {")
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk