httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: woah, "GET /" with autoindex
Date Sun, 07 Jan 2001 21:29:03 GMT

> > I agree this is a showstopper for the release, I believe it is fine to
> > release a beta with this issue.  There are multiple attacks for solving
> > this problem.
> 
> my main concern with calling it a showstopper is that i don't know
> what the APIs look like yet... and maybe they'll need changing to fix
> these bugs.  if you're cool with API changes during beta then it's not
> a beta showstopper.

The API's shouldn't change, because 

> > #1, the sbrk's.  We need to keep a list of free buckets, and not allocate
> > a new bucket each time we create one.  At some point, each process will
> > create a maximum number of buckets, and we will stop allocating new ones.
> 
> are you allocating the buckets out of the request or connection pool?
> or via malloc?  if it's malloc or otherwise shared across multiple
> threads then we'll run into lock contention on the list/malloc (on
> multi-CPU boxes only).

The buckets are allocated using malloc, because they need to be able to
move from the request to the connection.  The bucket_list will need to be
locked, preferably using a simple atomic increment/decrement lock.

> > This solves half the problem, but we are still allocating FAR too many
> > buckets for auto-index's.  The problem is that auto-index was written for
> > the old API, and we haven't tried to optimize that API yet.  The ap_r*
> > functions should all buffer data, so that they don't create a bucket per
> > char.
> 
> i don't really see ap_r* as the problem, i see ap_bucket_putstr/printf
> as the problem.  fixing ap_r* just helps folks writing code within httpd,
> it wouldn't help folks using buckets in other apps.

The thing is, our bucket implementation really relies on people knowing a
lot about their data.  I think that ap_bucket_putstr/printf should just go
away.  They don't really work, and they were added long before we arrived
at our current API for the buckets.  There is a reason nobody ever used
them when porting our modules.

> > We don't force zero-copy on anybody, but the core needs to figure out how
> > to buffer the data, which is just going to take somebody putting the logic
> > in.  It's not terribly complex, but nobody has had the time/inclination.
> 
> yeah, there's not much logic.  if a module uses ap_r{put,printf} then it
> should be buffered (one-copied), if it uses ap_rwrite/sendmmap/sendfile
> then it should be zero-copied.  that's essentially what 1.3 does... and
> seems to work fine.

Modules really shouldn't be using those interfaces anymore.  Any module
that uses those interfaces is essentially going to be doing
one-copy.  Modules that really want to perform will create buckets, and
store data in the buckets directly.  Or, they will create their own bucket
types, and just use those.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message