httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: is it possible to mark buckets to be copied only when to be set-aside?
Date Wed, 19 May 2004 19:50:12 GMT
Cliff Woolley wrote:
> On Wed, 19 May 2004, Cliff Woolley wrote:
>>can't just ignore APR_ENOTIMPL for bucket types, because pipe and socket
>>buckets never had setaside implemented on them.  I thought I remembered
>>that that was because Greg and Ryan and I had some huge debate about it
>>and it was decided for some reason that setting aside a pipe or socket
>>didn't make sense.  But now I can't find where we talked about that in the
> BTW - I remembered the reason why it was decided that it didn't make sense
> to implement setaside for pipe/socket buckets.  It's because for all other
> bucket types, setaside takes one bucket in and produces one bucket out,
> whereas for pipes and sockets it would take one bucket in and either
> produce one bucket if the lifetime request was already satisfied or it
> would produce a chain of n buckets out where n is proportional to the size
> of the data that had been waiting around to be read in the pipe/socket.
> It was that inconsistency that was disliked.  At this point, I'm willing
> to agree to whatever makes things work and would probably accept this
> inconsistency as long as it's documented.  What we have now is bug-prone
> beyond belief.

And a lot of pain and wasted time could be saved if all this was documented. 
I'm not aware of such documentation's existance, besides very scarce notes in 
the header files. Filters are a very complex area, and w/o proper user docs 
it's no wonder that we see all these problems.

The worst part is that some of the developers who originally wrote things are 
no longer here to help, so their knowledge and reasons, for doing things in 
certain ways, get lost.

I wish someone who groks filters well could write a proper document explaining 
most of (all?) the ins and outs of writing a proper filter. The old article 
written by rbb is nice, but a way too short to cover all the nuances.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message