X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <46E006AB.F600C446@dessent.net>
Date: Thu, 06 Sep 2007 06:54:51 -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>
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:

> So it seems to be a pretty high hurdle to have full windows
> compatibility here, and frustratingly I don't really understand the aim
> or the purpose.  For code that is going to link with Windows/msvcrt,
> using mingw is an obvious first choice, and the correctness guarantee is
> likely critical.   For code that is going to link with cygwin1.dll, I'm
> having a hard time seeing where this capability is needed: the anecdotal
> evidence on this list and others over the past few years seems to agree
> with my own perception that the speed performance loss is conceded to
> solve a recondite theoretical issue for most Cygwin users.   Not to say
> that the constraint isn't technically real, but it it worth killing the
> Cygwin platform for Octave et al when mingw is available for those that
> need it?

I think you're confusing the two separate issues, or maybe I didn't
transition from one to the other very clearly.

The reason we ship with SJLJ is because the Dwarf unwinder (prior to gcc
4.3) can't deal with foreign frames.  You can run into this simply by
writing a Windows GUI app, since the winproc is a callback.  This is
unrelated to whether you have static or shared libgcc, or exceptions
across libraries, or cygwin1.dll/msvcrt.dll.  I don't know how many
people use gcc 3.x to write Win32 GUI apps that use exceptions, but
without SJLJ I think it would be near-impossible to do this.  And that's
not a very far fetched or abstract idea: Cygwin's own setup.exe is a GUI
C++ app that uses exceptions, and it would fail miserably with 3.x
Dwarf2 EH.  You can't just say "sorry, gcc can't be used to write
Windows GUI apps if you want to use C++ exceptions."

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/