Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Thu, 15 Feb 2001 17:17:50 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: Egor Duda <cygwin AT cygwin DOT com>
Subject: Re: Optimizing away "ReadFile" calls when Make calls stat()
Message-ID: <20010215171750.A10277@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: Egor Duda <cygwin AT cygwin DOT com>
References: <4 DOT 3 DOT 1 DOT 2 DOT 20010213134821 DOT 019a7130 AT pop DOT ma DOT ultranet DOT com> <20010213190131 DOT 14369 DOT qmail AT lizard DOT curl DOT com> <200102131935 DOT OAA09136 AT envy DOT delorie DOT com> <20010213194612 DOT 17311 DOT qmail AT lizard DOT curl DOT com> <200102131954 DOT OAA09284 AT envy DOT delorie DOT com> <20010213152313 DOT A12830 AT redhat DOT com> <39319402546 DOT 20010214110838 AT logos-m DOT ru> <3A8C3254 DOT 505A4AAE AT etr-usa DOT com> <4 DOT 3 DOT 1 DOT 2 DOT 20010215160534 DOT 04a66d40 AT pop DOT ma DOT ultranet DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <4.3.1.2.20010215160534.04a66d40@pop.ma.ultranet.com>; from lhall@rfk.com on Thu, Feb 15, 2001 at 04:09:46PM -0500

On Thu, Feb 15, 2001 at 04:09:46PM -0500, Larry Hall (RFK Partners, Inc) wrote:
>At 02:47 PM 2/15/2001, Warren Young wrote:
>>Egor Duda wrote:
>> > 
>> > the  only problem with this approach i can see is that if we introduce
>> > new  API  and applications start to use it we became "bound" to it and
>> > it'll  be  not too easy to deprecate ad remove it afterwards. OTOH, we
>> > can  always  make stat_lite() a simple wrapper to stat() if the latter
>> > become fast enough.
>>
>>I like the idea of stat_lite(), and I don't see a reason to ever
>>deprecate it: it's simply a fact that stat() is a bad interface to Win32
>>functionality.  It exposes a Unix filesystem's inode element, and
>>therefore makes programs dependent on it.  To eliminate the need for a
>>stat_lite(), you'd have to redesign Win32, which is out of our hands.
>>
>>Here's how I think stat_lite() should be designed: give it one extra
>>parameter, a bitfield, over regular stat().  This declares what fields
>>are important to the caller.  
>>
>>All the code in the DLL's current stat() implementation would move to
>>stat_lite().  Then add 'if's checking the bitfield flags before making
>>Win32 calls to look up field values.  The DLL's stat() implementation
>>then becomes a wrapper around stat_lite(): it just sets all the bitfield
>>flags, telling it to look up every field value.
>>
>>If this design is used, stat_lite() would be a misleading name.  How
>>about stat_select(), since it would behave like select(2)?
>>
>>Example code:
>>
>>         struct stat st;
>>         stat_select("foo", &st, ST_MODE | ST_MTIME);
>>
>>Cygwin.DLL:
>>         int stat(const char* file, struct stat* pst) 
>>         {
>>                 return stat_select(file, pst, 0xFFFFFFFF);
>>         }
>
>
>
>Sure, this is an idea for new, Cygwin specific code.  I'm not quite 
>sure why someone who was writing new code (or changing old) wouldn't just
>use Win32 APIs to accomplish the required task though.  I mean, so long as 
>the change results in non-portable code, why not pick the less specific 
>Win32 APIs (over some Cygwin-specific alternative)?  Still, if you want to 
>implement such a patch and submit it, I'm sure it will get some thoughtful 
>consideration.

Egor has already submitted a patch like this and I've been mulling it
over for... a year maybe?

I think I can actually change Cygwin to do the right thing here without
any new API changes.

Stay tuned.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple