httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server request.c
Date Fri, 09 Nov 2001 16:30:06 GMT
From: "Greg Ames" <gregames@remulak.net>
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




Mime
View raw message