httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject Re: ap_save_brigade vs ENOTIMPL setaside
Date Fri, 01 Oct 2004 15:16:13 GMT
On Fri, 1 Oct 2004, Joe Orton wrote:

> There is a problem with this new logic: the mod_perl SV bucket type
> happens to be a case where ->setaside() is ENOTIMPL (currently) and
> ->read() does not morph the bucket type, so then ap_save_brigade() will
> abort without doing any work which is quite nasty.

That sounds like a bug in the mod_perl SV bucket type.  ->read() is
supposed to be defined such that the result of the read is a bucket that
*can* be set aside.

>From apr_buckets.h, starting at line 76:

  * read returns the address and size of the data in the bucket. If the
  * data isn't in memory then it is read in and the bucket changes type
  * so that it can refer to the new location of the data. If all the
  * data doesn't fit in the bucket then a new bucket is inserted into
  * the brigade to hold the rest of it.

In other words, if the data is not in memory, ->read() should put it there
and morph the bucket type.  If it is already in memory, then ->setaside()
should be implemented.

The logic to deal with all this is already complicated enough from the
caller's perspective... I'd rather not make it even *more* complicated
just to deal with broken bucket types.

--Cliff

Mime
View raw message