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
Message-Id: <4.3.1.2.20010215160534.04a66d40@pop.ma.ultranet.com>
X-Sender: lhall AT pop DOT ma DOT ultranet DOT com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 15 Feb 2001 16:09:46 -0500
To: Warren Young <warren AT etr-usa DOT com>, Egor Duda <cygwin AT cygwin DOT com>
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject: Re: Optimizing away "ReadFile" calls when Make calls stat()
In-Reply-To: <3A8C3254.505A4AAE@etr-usa.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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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.



Larry Hall                              lhall AT rfk DOT com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



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