Slowness problem due to sjlj-exceptions for Octave

Brian Dessent
Fri Sep 7 12:40:00 GMT 2007

Anthony Heading wrote:

> Even if you catch the exception before it plummets through the
> Windows API?

Well sure, but that's not realistic.  The entire windowing engine is
based on callbacks so it's unavoidable that there will be foreign

>  It seems clear I am not understanding something
> that you're taking as an obvious truth.  So let me try to state
> my assumptions in case they're wrong:

Here is the basic skeleton of any windows GUI app, vastly simplified:

int WINAPI WinMain(...)
  MSG msg;

  wc.lpszClassName = "SomeClassName";
  wc.lpfnWndProc = WndProc;

  HWND hwnd = CreateWindow ("SomeClassName", ...);
  ShowWindow(hwnd, ...);

  // the message pump:
  while (GetMessage(&msg, NULL, 0, 0))

WndProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
  switch (uiMsg)
      case WM_CREATE:
        // logic for OnCreate
      case WM_SIZE:
        // handle resizing
      case WM_DESTROY:
        // etc
      case WM_PAINT:
        // repaint myself
  return DefWindowProc (...);

All of the actual processing of all window events happens through
messages passed to WndProc, but WndProc is never directly called by user
code.  So if you want to communicate information between the window
procedure and the main function (such as: bad error happened, we need to
bail!) you wrap the message pump with a try/catch and throw from the

>   1) The Dwarf unwinder only needs to understand the frames that it
>      is considering unwinding.  If an exception is thrown and caught
>      within a contiguous sequence of gcc frames, it doesn't matter
>      what strange or foreign structures are deeper in the stack,
>      because the unwinder never sees them.

Completely true, but unrealistic.

>   2) It's necessary or prudent to catch gcc exceptions before they
>      fall into windows callback code.  I've never tried throwing a
>      g++ exception in a winproc handler and seeing if it makes
>      an express journey through user32.dll and back to the message
>      loop; but even if it seemed to work I'd be wary that windows
>      cleanup was being missed.

The problem is the WndProc is never called directly by the user, so by
definition when the unwinder looks at the next frame up it will be
inside the operating system/window manager somewhere.

I don't know how many users it would affect to simply decree "thou may
not throw from inside a WndProc" but I'm positive it would be nonzero --
this is not an obscure corner case.  You might argue that most people
doing Win32 GUI stuff use MinGW, but a lot of them use Cygwin with
-mno-cygwin which is MinGW with Cygwin build tools, a very convenient
combination.  And we can't offer a DW2 Cygwin gcc that uses SJLJ for
-mno-cygwin as they are really both the same back-end just with
different headers and runtimes.  (Again, our own setup.exe is a prime


Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list