httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] bucket problems.
Date Wed, 17 Jan 2001 20:49:38 GMT

> I think the very idea of an API which adds to a brigade is
> problematic.  We want an API which handles output, sending it down the
> filter chain when necessary (i.e., when our x-kilobyte coalesce buffer
> is full).  With your API, some weirdo will create a filesystem with
> infinite entries in a directory, and rather than having mod_autoindex's
> processing of this directory limited by network I/O to the client,
> mod_autoindex will loop until all storage is exhausted.

You are taking a part of the patch that was a quick hack and extrapolating
that it is the only way to do this.  I added the pass_brigade where I did
because I wanted a working example.  A real example will actually have to
make this call whenever it makes sense.

> I really think we want some changes with the coalesce property but
> also the flush-to-the-network-as-we-go property, rather than
> continually building up the brigade until the module sees fit to call
> ap_pass_brigade().

If you can design/implement this, please feel free.  As I see it, we have
multiple people with different priorities.  This is what I have currently
heard as priorities, please add any if I miss some.

Don't change the ap_r* API at all
Good performance for ap_r* functions
Ability to use both ap_bucket_create and ap_r* functions in the same
	function
Ability to use network congestion to stop sending data
Don't allow the server to even try to use up all the memory

You can't have all five of these.  Pick a few and design for them.

> But to do that the API needs to know about filters too (enough to call
> ap_pass_brigade()), so there is another parameter to
> ap_brigade_something().

No, that is tying the buckets to the filters, which ties buckets to Apache
basically, which is not correct IMHO.  The other option is to pass a
bucket_brigade to ap_r*, and pass things down when the brigade gets too
large, this would be realtively easy to do, but it requires modifying the
ap_r* API, which we were told is a no-no.  This also gets very confusing,
because when you use ap_r* you don't have to call ap_pass_brigade, but if
you don't use ap_r* you do need to make that call.  I have to say that if
you really want to confuse people, then offer five different ways to
generate content.

> many people will mix calls to fprintf() with calls to write()?  (Okay,
> you can but you gotta get stdio to flush before bypassing stdio...  We
> can allow that with ap_rXXX() too.)

It doesn't matter.  The biggest problem with Victor's patch is that it
puts the buffer in the request_rec, which means that we aren't helping
anybody other than Apache itself.

Ryan

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








Mime
View raw message