Avoid collisions between parallel installations of Cygwin

Brian Ford Brian.Ford@FlightSafety.com
Tue Oct 13 17:38:00 GMT 2009

On Tue, 13 Oct 2009, Christopher Faylor wrote:

> On Tue, Oct 13, 2009 at 10:22:05AM -0500, Brian Ford wrote:
> >On Tue, 13 Oct 2009, Christopher Faylor wrote:
> >
> >> The policy of "always use the newest" still makes sense to me.
> >
> >Disclaimer: We are not the Red Hat customer who payed for this feature.
> >
> >This policy only makes sense in an ideal world where complete backward
> >compatibility is guaranteed by the development team, and where any new bugs
> >introduced are rapidly fixed.  I submit to you that this is not the case
> >in reality from our own experience from 1.5.18 through 1.7, and is a
> >nearly impossible goal, especially for a volunteer open source software
> >project.
> >
> >For example, I'm aware of few times where our original application built
> >and working under 1.5.18 did not have a significant issue with newer
> >versions; many of which were complete show stoppers.  Some of these issues
> >were due to policy changes that decided it was ok to break previous
> >behavior because is was deemed to never have been "officially supported".
> >Some were due to "bug fixes" that changed behavior to make it more like
> >Linux, others were due to bug fixes that significantly effected
> >performance, and still others were due to introducing new bugs when new
> >features were added.  If anyone really wants the complete chronological
> >list, I can provide it, but I don't think the details are where the point
> >lies.
> Of *course* we want details.

Ok, I'll provide them to the best of my memory.  The fine details of which
may take me a while to recall if you want further information.

Policy changes:
1.5.19 no longer synchronizes the Windows and Cygwin environment
(cygwin_internal hook added in 1.5.20)
1.5.19 high resolution timing no longer supported (timeBeginPeriod(1 ms)

Simple bugs:
1.5.18 spawnve was broken
1.5.19 nanosleep was broken
1.7.x  deadlock with multiple threads accessing one socket (my fault, I
haven't notified or provided a test case yet as this is arguably bad app
behavior even though it worked in 1.5.18)

Linux bug fixes:
1.5.19 Added exe to /proc/self/exe

Performance issues:
1.5.19 I/O performance degraded severely due to signal handling fix
http://cygwin.com/ml/cygwin-developers/2006-07/msg00029.html etc. mostly
restored now in 1.7

New feature bugs:
1.5.20 MAP_NORESERVE not correctly implemented
1.5.21 MAP_NORESERVE better, but no supported when passed as buffer to
system calls

Obviously the new feature bugs only affected new app builds.  Many
temporary issues also existed with CVS versions, snapshots, and
experimental releases as can be expected.

I'm sure there are a few more that I don't recall or didn't document.
IIRC, 1.5.25 was mostly ok except for I/O performance and 1.7.x is now ok
except the threaded socket deadlock I mentioned above.  Overall, it
doesn't look as bleak as I remembered, but it is a comedy of errors
preventing upgrade due to the usual some bugs fixed, some bugs introduced
problem.  Frustration tends to build when that persists for significant
calendar time, but I understand this is a volunteer effort.

> It is funny that you chose this particular discussion to make this
> point, however.

I don't understand this statement at all.  It seems particularly relevant
to this discussion to me.

Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

More information about the Cygwin-developers mailing list