Re: [Mingw-users] GCC 4.3.0 20080502 (alpha) Released - Please help us test it!

[ATS <asteinarson@xxxxxxxxx>]

> > gets semantics very close to what MS VC++: 
> > 
> >    try {
> >       *(int*)0 = 0;
> >    } catch ( SignalException* pse ) {
> >       printf( "Exception condition: %s\n", pse->GetReason() );
> >    }
> > 
> 
> Thanks for pointing this out.  Just off the top of my head, there is 
> some chance we can make this work with MinGW GCC as well.  I'll look 
> into it.
> 

Yes, in a limited sense. There's a win32 function _set_se_translator(...) 
that installs a function whose only job is to 'translate' a SEH exception
into a C++ exception. You exit the SEH translation function with:

  throw SomeCppException(error_descr);

But, with DWARF we would still limited when it comes to throwing across
foreign frames.


> > This provides a safety net when loading plugins or other running other 
> > code that one has not built oneself. Without a mechanism like this, the
> > app is doomed whenever 3rd party code does a NULL pointer access or 
> > divide by zero. For me this is a crucial feature. 
> 
> MinGW can do it presently using the 'manual' SEH interface in <expt.h>, 
> but it isn't nearly as pretty.
> 

When a 3rd party component does something like NULL pointer access, you
also want stack unwinding (when recovering up to the 'try' block). At 
least for your own frames. That's one thing you get by translating it 
into a C++ exception. 

Imagine what would happen if an Apache server simply would exit each 
time some module does a NULL pointer access. If you have some plugin 
architecture (like loading Python modules), the whole app is at risk 
each time when executing loaded binary code, if there is not a robust
recovery mechanism (including stack unwinding).

So there seems to be a choice between:

1 - DWARF - Fast but not robust with foreign frames. (any code generated
by other compiler, in a plugin / DLL / static lib from 3rd party).

2 - SJLJ - A bit slower but robust recovery in a mixed/plugin environment.

For me, the choice is 2 since I work with extensible apps. Since there 
are so many compilers for Windows and run-time binary linking (plugin/
COM) is common, it seems SJLJ is a better match. 


> However, the problem is not that the exception throwing or catching is 
> slow.  The problem is that merely passing through a try {} block or 
> exception specification such as throw(std::bad_alloc) has a small 
> penalty, which can be measurable in tight loops.  DW2 completely solves 
> the problem, by having no direct runtime cost at all.

If there is a try block inside a crucial tight inner loop, I'd just move 
the try block out of there (I imagine one can shift the design slightly 
in most cases).

Does entering a function that throws have a cost with SJLJ?? Sounds 
strange to me. That 'try' has a cost is obvious, since we have to 
save recovery state into a chain of handlers there.

If the choice is between:

 - Robust recovery in a mixed binary environment (with a cost for 
   every 'try' block)

 - Very optimized performance in a controlled homogeneous environment
   (limited, special circumstances, particularly on Windows)
 
then that choice is easy enough for me.


So many apps are dependent on run-time plugin loading (as the mentioned
Apache, Open Office, Nodzilla). Even using ordinary C callback functions
with static libs, one is at risk.

Regards
// ATS.


> I think SEH might be close that 'light weight' mechanism you propose, as 
> it doesn't save state, and uses a per-thread mechanism.
> 

> Unfortunately, MinGW maintainers do not have the resources to write a 
> new exception model; we don't even have resources to implement SEH, a 
> frequently-demanded feature.
> 
> However, the problem is not that the exception throwing or catching is 
> slow.  The problem is that merely passing through a try {} block or 
> exception specification such as throw(std::bad_alloc) has a small 
> penalty, which can be measurable in tight loops.  DW2 completely solves 
> the problem, by having no direct runtime cost at all.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> MinGW-users mailing list
> MinGW-users@...
> 
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> 
> 





-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users