Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 7 Jun 2005 10:28:42 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Performance problems
Message-ID: <20050607142842.GH16960@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20050528131501 DOT V53507 AT logout DOT sh DOT cvut DOT cz> <20050528160424 DOT GB12395 AT trixie DOT casa DOT cgf DOT cx> <429ED094 DOT 9080001 AT tlinx DOT org> <Pine DOT GSO DOT 4 DOT 61 DOT 0506021301320 DOT 10282 AT slinky DOT cs DOT nyu DOT edu> <20050602172226 DOT GC6597 AT trixie DOT casa DOT cgf DOT cx> <42A2246D DOT 3090000 AT tlinx DOT org> <20050605005508 DOT GA2706 AT trixie DOT casa DOT cgf DOT cx> <42A3BC5C DOT 1090605 AT tlinx DOT org> <20050606034652 DOT GB9161 AT trixie DOT casa DOT cgf DOT cx> <42A4FDB2 DOT 4030205 AT tlinx DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42A4FDB2.4030205@tlinx.org>
User-Agent: Mutt/1.5.8i

On Mon, Jun 06, 2005 at 06:51:46PM -0700, Linda W wrote:
>><And as soon as you start timing out your cache, you either have a
>>separate thread running which manages this (which implies careful
>>attention to locking issues and context switching) or you a schedule
>> timer signal (which has similar problems).)
>> 
>>
>This may not be necessary if you only cache file handles within
>1 execution of a program (like find), so that file-ops within the same 
>program achive speedup.  You could time-out cache entries on an
>as-needed basis or timer.

Let me say it again.  You can't keep files open for an arbitrarily long
time.  That means that you need some method to invalidate entries in the
cache.  That means another thread running to sweep the cache.  That means
locking and added complexity.

>>I was filling in the details here just to show that the solution of
>>keeping files open has consequences.  Keeping the file open increases
>>the complexity of every function which manipulates a file rather than
>>the one or two functions which might be interested in the cached status
>>information.
>>
>True...but ideally we are only talking about caching & leaving open
>file desriptors within 1 or 2 clockticks -- within the same program.
>If another cygwin program requests deletion of the file, schedule it
>for deletion when it becomes uncached.

It doesn't matter how long the handles are open.  Any cygwin function
that deals with files would have to be aware that the handle was open.

>Sure, I'm sure you and I both can come up with infinite ways that
>it might be implemented in a broken manner.  I guess I'm
>operating under the assumption that it would be done correctly --
>with the ability to turn it on/off via a CYGWIN var or such,
>while it is being developed. 

I wasn't talking about anything being "broken".  I was talking about
increasing complexity in cygwin and the fact that this isn't a simple
problem and that you can't just say "It will speed things by X because
we're removing all of these extra calls to stat() (or whatever)".

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/