X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <46E146D0.9C1F7289@dessent.net>
Date: Fri, 07 Sep 2007 05:40:48 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Slowness problem due to  sjlj-exceptions for Octave
References: <20070905080321 DOT 29259AB0 DOT matsuoka AT mol DOT nagoya-u DOT ac DOT jp> <46DE0C86 DOT 61C0ABB0 AT dessent DOT net> <46DFFE96 DOT 70907 AT ajrh DOT net> <46E006AB DOT F600C446 AT dessent DOT net> <46E0D4F7 DOT 1050006 AT ajrh DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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
frames.

>  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(...)
{
  WNDCLASS wc;
  MSG msg;

  wc.lpszClassName = "SomeClassName";
  wc.lpfnWndProc = WndProc;
  ...
  RegisterClass(&wc);

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

  // the message pump:
  while (GetMessage(&msg, NULL, 0, 0))
    {  
      TranslateMessage(&msg);
      DispatchMessage(&msg);
    }
}

LRESULT CALLBACK
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
WndProc.

>   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
example.)

Brian

--
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/