strange crashes on invocation

Corinna Vinschen
Sat Sep 25 18:46:00 GMT 2010

On Sep 24 18:36, Corinna Vinschen wrote:
> On Sep 24 10:07, Christopher Faylor wrote:
> > On Fri, Sep 24, 2010 at 12:48:50PM +0200, Corinna Vinschen wrote:
> > >What I'd like to propose is to minimize autoloading to the entry points
> > >which are not available on all OSes.  Other than that, we should link
> > >cygwin against all used system DLLs so it can profit from the fixed
> > >DLL addresses and the potential speed advantage the DLL sharing grants.
> > 
> > I don't see how fork enters into this since Cygwin doesn't have any
> > visibility into the data in a system dll.  It shouldn't matter where one
> > of these guys is loaded.
> Yes, in theory.  I was just thinking that this somehow looks like a
> situation which appears to be similar to what happens in fork if a DLL
> can't be loaded at the right spot.  I can't imagine why loading
> ws2_32.dll works most of the time but sometimes fails for no apparent
> reason.  Of course there are still three possible other solutions:
>   - Bug in ws2_32.dll
>   - Bug in cygwin1.dll
>   - Bug in application
> > But, coincidentally enough, I was thinking the
> > same thing about dropping the dynamic linking.  It is less important now
> > that we no longer support Windows 9x.
> > 
> > The other motivation for the autoload stuff was supposed to be reducing
> > the runtime link cost of resolving symbols that would never be used.  It
> > would be interesting to see if there is any noticeable performance change.
> > I could see it either getting faster or slower.
> I'll do some speed comparisions over the weekend.

The results are terrible.  There are three system libs which have no
visible impact when being linked against (ws2_32, secur32, rpcrt4).  The
others have a performance *hit* from 2.5% (user32), up to 25% (iphlpapi,
shell32).  In no way do the results support the point I was trying to
make.  Autoloading rulez.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list