|
yubing
trueice at gmail.com
Wed Jul 4 00:07:47 EDT 2007
oh, that's almost the same as the ap_rwrite and ap_rflush On 7/4/07, yubing <trueice at gmail.com> wrote: > > quite right, thanks a lot:) > Then is the connection object suitable for my case? It seems request based > handling is just for short connections, and conn_write() has its own pool > mgmt code: > > > if (len) { > buff = apr_pmemdup(c->pool, PyString_AS_STRING(s), len); > > bb = apr_brigade_create(c->pool, c->bucket_alloc); > > b = apr_bucket_pool_create(buff, len, c->pool, c->bucket_alloc); > APR_BRIGADE_INSERT_TAIL(bb, b); > > /* Make sure the data is flushed to the client */ > b = apr_bucket_flush_create(c->bucket_alloc); > APR_BRIGADE_INSERT_TAIL(bb, b); > > ap_pass_brigade(c->output_filters, bb); > } > > > > > On 7/4/07, Graham Dumpleton <graham.dumpleton at gmail.com> wrote: > > > > On 04/07/07, Graham Dumpleton <graham.dumpleton at gmail.com > wrote: > > > On 04/07/07, Graham Dumpleton <graham.dumpleton at gmail.com> wrote: > > > > On 03/07/07, yubing <trueice at gmail.com > wrote: > > > > > Anyhow, it's clear that ap_rflush is the root cause of this memory > > leak, > > > > > maybe we should find a new API for this (maybe we should also add > > a new > > > > > method to the request_object ). > > > > |