This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Performance problems
<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.
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.
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'd start with defaulting to off and then start adding code
which would be enabled when I set some "CACHING_TIME" or CACHING_FDS"
variables in "CYGWIN", for example. Once I thought it worked
well and passed most of my tests, announce functionality and let
those who want to test it out, turn it on.
If it is stable, at some future point, it could default to ON but
still allow turning it off if it causes someone's apps to misbehave.
It's similar to the "synchronous" write flags on network and hard
disk shares. If you need synchronous operation, you live with the
performance penalty of synchronous writes. However, most people seem
to find asynchronous writes to be acceptable.
This is already a problem even w/o caching. Cygwin can't delete
various directories because they are kept open by the login shell.
Being unable to consistently delete a file because something has it open
is explainable. What isn't explainable is "Why does my configure script
work some times but not others?" When you talk about keeping caching information
around, you stand the chance of something like this not working:
find . -name foo | xargs rm
because find may still have foo open when rm tries to remove it.
---
Parallel processes processing the same files could be tricky.
That's where inter-process knowledge of cached files would be handy --
specifically to handle deletion on close. No one is saying
caching is simple, but done in some limited form could speed up
things considerably, with the primary purpose being to speed up
POSIX emulation within the same process. Providing safety nets
to ensure that POSIX programs are aware of the other POSIX
programs that might be accessing the same file would guarantee
correct operation under cygwin -- but if you mix cygwin with
windows-unix and windows calls...well that can just be confusing.
As for the OS making changes to a file outside of cygwin -- I
thought it was possible to monitor an open-file descriptor and be
notified when there were changes done on the file. Isn't that the
basis of the automated Windows file check&repair facility?
-l
--
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/