Avoid collisions between parallel installations of Cygwin
Wed Oct 14 16:08:00 GMT 2009
On Tue, 13 Oct 2009, Christopher Faylor wrote:
> On Tue, Oct 13, 2009 at 12:38:34PM -0500, Brian Ford wrote:
> >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)
> I googled this and see you complaining about it.
By this, I assume you mean the timing resolution as opposed to the Windows
environment synchronization. I just want to make it clear that I'm not
exactly complaining, just noting that it was a policy change that affects
application behavior and expectations.
> It isn't exactly clear what your complaint is or how it relates to a
> modern Cygwin.
My "complaint" was that Cygwin circa 1.5.18 (and several 1.5.x versions
before; I forget when this originally went in) chose to increase the
system tick resolution as seen by application scheduling (of system sleeps
and timers) and system time (as reported by gettimeofday, etc.). That
policy was later revoked because of performance impact and overhead
I consider Cygwin to be roughly equivalent to an OS (given the obvious
underlying Windows restrictions), and it is unusual for a minor OS version
change to radically (an order of magnitude) change it's scheduling and
timing resolution. I agree that most user applications would not notice
this change, but sometimes timing is important to application behavior,
even for standard user applications.
> It isn't clear that these aren't actually just bugs.
Synchronizing the Windows environment with the Cygwin one, and increasing
the scheduling and system time resolution are bugs that need to be fixed?
Then why was the cygwin_internal call created to work around the bug fix?
I assume you mean that you consider these to be application bugs because
these behaviors should not be expected.
> My point is that you waited years to mention what you consider problems
> with backwards compatibility and then used this opportunity, where I
> reiterate a standard cygwin policy, to say "Oh no it isn't!"
I didn't wait years; I brought each of these up at the time. The Cygwin
developers (as is their right) deemed these issues not to be a significant
backwards compatibility issue, and I accepted that decision. I'm just
pointing out cases where your policy assumptions of newer is always better
can be problematic in real world situations. I'm not being adversarial in
> Most of the above are bug fixes however, which I would say proves my
> point since you don't see bug fixes in 1.5.20 which permanently go away
> in 1.5.21.
I'm at a loss to understand this statement. Sorry, I guess I'm
particularly dense lately.
> No one claims that there won't be problems with releases. However you
> could use the above to justify the "always use the latest version". If
> someone decided to package 1.5.20 then MAP_NORESERVE would be
> permanently broken in their package until they realized the mistake.
> The point of using the latest version is that we fix bugs as we find
> them. We don't fix bugs in versions of cygwin included with other
> people's packages.
No one is asking you to do that. We are only asking for you to allow
those other people to determine if they want those fixes and the
associated other bugs and changes in behavior that go with them.
I'm using the above to show that although many things are better in the
latest version, some things have changed enough to not be backward
compatible with previous application assumptions. Often the some things
fixed, some things broken problem can persist for some duration,
especially in a volunteer free software environment. Thus it is useful
for someone distributing a specific application (free or otherwise) to
assure that it works correctly by preserving the environment in which it
was tested. This includes avoiding upgrades of dependent libraries even
when they supposedly assure backward compatibility.
> I'm obviously not saying that everything is always guaranteed to be
> pristine and perfect in every Cygwin release. There is, however, a
> general trend towards improvment so it makes general sense for people to
> use the latest version. However, I've also repeatedly said that if
> someone is responsible for a large installation that uses Cygwin they
> would be daft (and I don't think you are) to just blindly install a new
> version and trust that we have been keeping their specific needs in
Agreed, and this is exactly why the proposed feature is useful. On one
machine, multiple applications using the Cygwin DLL in different ways need
the controlled independent solution you describe above.
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
the best safety device in any aircraft is a well-trained crew...
More information about the Cygwin-developers