Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 27442 invoked by uid 500); 9 Nov 2001 16:30:57 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 27431 invoked from network); 9 Nov 2001 16:30:56 -0000 Message-ID: <010b01c1693b$e4e93440$93c0b0d0@v505> From: "William A. Rowe, Jr." To: , References: <20011109080843.32331.qmail@icarus.apache.org> <3BEC013B.9E57E346@remulak.net> Subject: Re: cvs commit: httpd-2.0/server request.c Date: Fri, 9 Nov 2001 10:30:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 09 Nov 2001 16:30:50.0756 (UTC) FILETIME=[E4E93440:01C1693B] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Greg Ames" Sent: Friday, November 09, 2001 10:15 AM > wrowe@apache.org wrote: > > > > wrowe 01/11/09 00:08:43 > > > > Modified: server request.c > > Log: > > Reintroduce the 'one stat dir_walk' > > Bill, > > How confident are you that this is rock solid? i.e., should I consider > bumping it into 2.0.28? It would be great if we could have the > performance benefit, but IMO stability is the top priority for a beta > candidate tarball. Agreed that stability is key - and this is optimization, not essential. However, I don't mind incorporating it into .28. > Bill S. said he'd test it on Win32. I can test it on Linux and FreeBSD. Please, do. Then let's draw it up for a few hours on apache.org to really pound on it. It is entirely possible this introduces a hole, but I doubt it. I see about five cases that it could cause trouble... then I rewalk the code and realize that they are already protected against. Thinks like skipping the final stat, well, we already glom the final stat outside of that loop. Come to think of it, the only scenario I can picture is; user requests a symlink (the final filename component) we stat -> optimize the loop gets down to that last element/symlink we optimize away the actual stat to the target file That's badness, but it's the only scenario I can picture. What if we take it a step further, and test 'is this the end?' before we go and skip that last lstat. In this case, we can skip the lstat, but we musn't skip the actual stat. Stat'ing the final target, rather than lstat'ing it, is no good, we would end up with a stat - lstat - stat sequence that is a waste. Bill