On Mon, Apr 27, 2020 at 6:17 PM Joe Orton <[email protected]> wrote: > > On Mon, Apr 27, 2020 at 04:27:56PM +0200, Yann Ylavic wrote: > > On Mon, Apr 27, 2020 at 4:11 PM Joe Orton <[email protected]> wrote: > > > > > > +1 from me for using the term "opaque buckets" as a synonym for > > > "e->length == (apr_size_t)-1" aka "buckets with indeterminate length". > > > > OK thanks, just committed "something" in r1877077 because I keep > > messing up with my attachments today. > > Let's discuss from "that" if needed.. > > That change is definitely better. Isn't the code still making the > assumption that FILE is the only possible non-opaque morphing bucket > type? > > http://svn.apache.org/viewvc/httpd/httpd/trunk/server/util_filter.c?revision=1877077&view=markup#l1108 > > ...and by "non-opaque morphing bucket type" the distinction intended > here is... "representing a determinate length bucket type which is not > fully mapped into RAM until you try read()ing it until exhaustion".
I wish you don't want me to find a variable name for this :) But yes, the code assumes that non-opaque buckets can be passed to ap_save_brigade() without mapping more than necessary to memory (by more than necessary I mean e.g. TRANSIENT to HEAP is fine, but morphing an fd to HEAP isn't). So the assumption is mainly that each bucket (besides opaque) implements ->setaside() in a "sane" manner. Are you aware of a non-opaque bucket type for which this is an issue? Note that there is nothing special about FILE buckets here, it's just that we know that they don't consume memory until read, so we don't account for their ->length against memory limits (flush_max_threshold). We don't do that for other buckets types, so their ->length do count. Regards, Yann.
