This is the mail archive of the cygwin mailing list for the Cygwin 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: gcc-dw2? or fast sjlj-exceptions EH


On 11-Sep-2007, Danny Smith wrote:

| At http://www.cygwin.com/ml/cygwin/2007-09/msg00194.html
| 
| Tatsuro Matsuoka wrote:
| 
| > The best solution, I think, the speed of sjlj-exceptions EH on the 
| > cygwin is as fast as that of other platforms.
| > 
| 
| In the case of octave, I believe that the main cause of slowdown is the
| sjlj EH code generated in prologue of new()
| Does a no-throw override of libary version of these functions help ?  

Octave does not set up a new handler because it expects that a failed
allocation will throw a std::bad_alloc exception.  Given that, it
seems that the replacement for operator new that you posted would
cause Octave to crash on a failed allocation, and that's not an
acceptable solution for an interactive system like Octave.

If we did install a new handler, could it throw a std::bad_alloc
exception and still avoid the performance problem?  I don't see how,
as it seems that would just be pushing the problem one function call
level deeper but without any real change in the way things work.

It's also not acceptable to install a new handler that doesn't throw
an exception but just does a longjmp because then all the nice cleanup
things that are supposed to happen with exception handling are
bypassed when recovering from the failed allocation.

jwe

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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