RE: [boost] Re: boost::execution_monitor impl under windows

From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-21 00:43:52

Carl Daniel wrote:
>_set_se_translator works just fine in release builds.

Agree. I don't know what is that all about. The book does not elaborate
there.

> This is true.  If, that is, you're relying on proper C++ unwinding
>semantics
> when an SEH is raised.  With /EHs, _set_se_translator will still be
called,
>but some C++ objects may not have destructors called, and the exception
may
>not be caught in the nearest enclosing scope.  This isn't a problem
with
>_set_se_tranlator, per se, but due to the fact that the c++ compiler
may
>optimize-out exception handling frames where it can show that no
exception
>can occur under the synchronous model.

That helps. So if you where to "throw" inside a translator, what happens
after that is not what you would think it should happen, that is, proper
stack unwinding at each nested level, but something more along the lines
of random behavior.

I wonder why VC does generate just a warning (level 4) about this and
not an error...

Reading David Abrahams' Guidelines at
http://www.boost.org/more/error_handling.html

Seems that a better execution_monitor will nicely complement them. That
is, if you subscribe to the camp that wants to avoid catch(...) whenever
possible then one should only catch specific kinds of exceptions and
whenever possible let execution_monitor handle the rest. 

CPU.

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Carl Daniel
Sent: Saturday, September 20, 2003 10:52 PM
To: boost_at_[hidden]
Subject: [boost] Re: boost::execution_monitor impl under windows

carlos pizano wrote:
> Hello Boosters. I am looking into the boost.test library for insights.
> In particular I like the boost::execution_monitor idea. However, I
> found
> that on Windows + VC execution_monitor implementation uses
> _set_se_translator() to translate native exceptions (SEHs) into C++
> exceptions, and I was fine with that for a while until I stumbled unto
> John Robbins book : "Debugging applications for Microsoft .NET and for
> Microsoft Windows" (Microsoft Press, 2003) chapter 13 specifically in
> pg. 524 he has section named "Don't Use _set_se_translator" where he
> goes to say that _set_se_translator:
>
> 1- Is not global, works only on a per thread basis

Naturally.  Since DLLs frequently create internal worker threads, a
global
SE translator function would be very inappropriate.

> 2- Does not work in release builds (!!)

_set_se_translator works just fine in release builds.

> 3- Forces your code to use asynchronous exception handling (/EHa),
> which reduces performance and maybe increases code bloat.

This is true.  If, that is, you're relying on proper C++ unwinding
semantics
when an SEH is raised.  With /EHs, _set_se_translator will still be
called,
but some C++ objects may not have destructors called, and the exception
may
not be caught in the nearest enclosing scope.  This isn't a problem with
_set_se_tranlator, per se, but due to the fact that the c++ compiler may
optimize-out exception handling frames where it can show that no
exception
can occur under the synchronous model.

-cd

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost