httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: Recall of input filter module on completion of output filterprocessing for a request???
Date Tue, 31 Aug 2004 07:15:54 GMT
Bojan Smojver <bojan@rexursive.com> writes:


[...]

> 
> I thought that the connection filters may delay delivery of a particular
> request output data, particularly if the payload is small. In other
> words, they may group all of it together to deliver in a single packet.
>
> Wouldn't that mean that by the time the connection filter (on the
> network level, for instance) gets to it, the brigade, including its
> contents, may be gone?

In theory: no, the core_output_filter calls ap_save_brigade() in those 
circumstances.  Take a look at the implementation...

AP_DECLARE(apr_status_t) ap_save_brigade(ap_filter_t *f, 
                                         apr_bucket_brigade **saveto,
                                         apr_bucket_brigade **b, apr_pool_t *p)
{
    apr_bucket *e;
    apr_status_t rv;

    /* If have never stored any data in the filter, then we had better
     * create an empty bucket brigade so that we can concat.
     */
    if (!(*saveto)) {
        *saveto = apr_brigade_create(p, f->c->bucket_alloc);
    }
    
    for (e = APR_BRIGADE_FIRST(*b);
         e != APR_BRIGADE_SENTINEL(*b);
         e = APR_BUCKET_NEXT(e))
    {
        rv = apr_bucket_setaside(e, p);
        if (rv != APR_SUCCESS
            /* ### this ENOTIMPL will go away once we implement setaside
               ### for all bucket types. */
            && rv != APR_ENOTIMPL) {
            return rv;
        }
    }
    APR_BRIGADE_CONCAT(*saveto, *b);
    return APR_SUCCESS;
}

 
> Actually, when I was testing a lot of pipelined requests, that's exactly
> the kind of problems I was experiencing. I guess I didn't something else
> wrong somewhere...

[...]

> > OTOH, the bucket's setaside function takes a pool argument for just
> > this reason, so in principle you should be able to use buckets created
> > from the request pool if you really want to.  Perhaps the problem
> > is really a wrong choice of bucket type, not the wrong initial pool?
> 
> Isn't the pool buckets' setaside also a NOOP?

Pool buckets are just lazy heap buckets.  The cleanup they use
just copies the bucket data into the heap if the pool vanishes
before the bucket does.


-- 
Joe Schaefer


Mime
View raw message