Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance

[Eric Blake <eblake at redhat dot com>]

[what part of NO TOP-POSTING don't you understand?]

On 09/29/2010 01:51 PM, Derry Shribman wrote:
> Hi,
>
>  > To be clear: we are definitely not going to create an interface (and I
>  > use the term loosely) to Cygwin which requires a program to internally
>  > use putenv() or setenv() to change behavior. That is just a really bad
>  > way to implement this type of thing since it is not how environment
>  > variables are meant to be used. Environment variables are meant to be
>  > used to externally control the behavior of a program.
>
> "TZ" env is an example of an env that is used inside applications to
> control application internal stuff.

And use of an env var to control behavior renders ALL such APIs 
non-thread-safe.  While it is fine for localtime() and friends to be 
non-thread-safe, it most certainly is NOT fine for stat() to be 
non-thread-safe (in fact, POSIX guarantees that stat() must work from 
signal handlers, which cannot be said for localtime()).

> I can do this in 2 lines:
> { static char e[1024]; snprintf(e, sizeof(e)-1,
> "%s no_ino no_nlink", getenv("CYGWIN")); setenv("CYGWIN", e, 1); }

And fail miserably when getenv("CYGWIN") returns more than 1024 bytes to 
begin with.  Don't even get me started.

> Cheap price to pay to make the application run way faster on Cygwin
> (a.k.a cygwin friendly).

But you have to make the guarantee that ALL calls to stat() will not be 
negatively impacted by this setting, including the calls inside library 
functions.  And as long as you ALREADY have to audit your code to make 
sure that all uses of stat() will not be impacted, you might as well 
already also change to xstat() in the process.  What's more, if you find 
an instance where you MUST have the full information embedded among 
other uses that don't care, xstat() gives you much better granularity 
than repeatedly tweaking an envvar.

> The env allows to do it all in one call on program init.

And allows you to screw yourself royally when you really should not have 
been using it.

--
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org