httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_cgi.c
Date Sat, 02 Sep 2000 15:24:13 GMT
> >                                 The reason it is important, is that it is
> > impossible to add the heap bucket created by reading from a pipe bucket,
> > in a single entity brigade.  That is the BS reason though.
> I fixed an unconditional b->next->prev reference in there recently
> which may explain that problem.  After that, I didn't see any breakage
> when cgi didn't add the EOS.

The problem is that the brigade has to have a pointer to the head and tail
of the bucket list.  In the read function, this is not possible to
accomodate.  By having multiple buckets in the list, we solve that
problem.  Without it, we leak memory.

> >                                                             the real
> > reason, is that it allows for so much flexability to have the content
> > generator say when it is finished generating content.  It just doesn't
> > make sense for Apache to say it is done, when the content generator is the
> > only thing that really knows when it is donr generating content.  The real
> > fix is to fix the rest of the handler functions, and remove the code from
> > the finalize protocol function.
> The generators already have a way to say they're done generating
> content: they return from their handler.  

But that doesn't provide the performance enhancements.  Think of it this
way.  We have a filter that adds a trailer to a web page.  If the handler
outputs the EOS, then the trailer filter can add it's single bucket on the
way down the stack, and everything can be sent using sendfile, because the
trailer will be using a file bucket.  (Assume we have enough data buffered
to send out even without the sendfile.)

If the handler doesn't output the EOS, then we send all of the regular
data, and then we return from the handler, the EOS is sent, trailer is
added, and we finally call sendfile, but it has no header
information.  This is where the EOS bucket is truly useful, and by not
allowing handlers to use it, we eliminate a good portion of it's

> Whatever...  I wasn't willing to decide that I understood all current
> uses of ap_finalize_request_protocol(); it seemed crystal clear that
> getting rid of the EOS in mod_cgi was a net reduction in the amount of
> breakage.

Yes, but a reduction in the wrong direction, because we will leak memory,
and that's no good either.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message