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: <3A8C3254.505A4AAE@etr-usa.com>
Date: Thu, 15 Feb 2001 12:47:32 -0700
From: Warren Young <warren AT etr-usa DOT com>
Organization: -ENOENT
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Egor Duda <cygwin AT cygwin DOT com>
Subject: Re: Optimizing away "ReadFile" calls when Make calls stat()
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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);
	}

--                                                   _
= 'Net Address: http://www.cyberport.com/~tangent | / \  ASCII Ribbon
= ICBM Address: 36.82740N, 108.02040W, alt. 1714m | \ /  Campaign
=                                                 |  X   Against
= Chance favors the prepared mind.                | / \  HTML Mail

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