OK, I have a clue why ap_save_brigade wasn't implemented. I looked at
its source and it basically does this:
# XXX UNTESTED CODE
sub Apache2::Filter::save_brigade {
my ($f, $saveto, $bb, $pool) = @_;
# XXX should this be $f->r->pool?
$pool ||= $f->c->pool;
my
Hello,
Is there a reason why ap_save_brigade hasn't been implemented? Does it
have special needs?
(Funnily, after googling this issue, I found I had asked the same
question in 2005:
http://mail-archives.apache.org/mod_mbox/perl-modperl/200505.mbox/%3c20050509222133.gb31...@foobarsystems.c
> I'm not getting very far with this, Dorian. Neither httpd-dev nor apr-dev
> are taking it anywhere. So at the moment ap_save_brigade is sort of an
> unstable API, so other developers think we shouldn't expose it in the core
> API. So at the moment you have two
Dorian Taylor wrote:
I'm not getting very far with this, Dorian. Neither httpd-dev nor apr-dev
are taking it anywhere. So at the moment ap_save_brigade is sort of an
unstable API, so other developers think we shouldn't expose it in the core
API. So at the moment you have two options:
Stas Bekman wrote:
Dorian Taylor wrote:
it'd be nice to run a benchmark. I wonder why ap_save_brigade was
marked as ! in the map file. Which normally means it's not going to
be exposed. Did you by chance look at the archives for possible
references to it?
there's a mention o
Dorian Taylor wrote:
it'd be nice to run a benchmark. I wonder why ap_save_brigade was marked
as ! in the map file. Which normally means it's not going to be exposed.
Did you by chance look at the archives for possible references to it?
there's a mention of it in the APR::Bu
> it'd be nice to run a benchmark. I wonder why ap_save_brigade was marked
> as ! in the map file. Which normally means it's not going to be exposed.
> Did you by chance look at the archives for possible references to it?
there's a mention of it in the APR::Bucket
thought. when i wrote this i just
wanted to make it go.
it'd be nice to run a benchmark. I wonder why ap_save_brigade was marked
as ! in the map file. Which normally means it's not going to be exposed.
Did you by chance look at the archives for
> How is that related?
i think that's some cargo culting that i didn't clean up. that can
be disregarded.
> So you think this approach will be faster than flattening bb on each
> filter invocation and concatenating the scalar?
honestly i didn't give it any thought. when i wrote this i just
want
brigade *saveto,
+ apr_bucket_brigade *bb,
+ apr_pool_t *p)
+{
+apr_status_t rc = ap_save_brigade(f, &saveto, &bb, p);
+/* if users don't bother to check the success, do it on their
+ * behalf */
+
apr_status_t rc = ap_save_brigade(f, &saveto, &bb, p);
+/* if users don't bother to check the success, do it on their
+ * behalf */
+if (GIMME_V == G_VOID && rc != APR_SUCCESS) {
+modperl_croak(aTHX_ rc, "Apache::Filter::save_brigade");
+}
+
+
Dorian Taylor wrote:
same issue, now with a function that exists. ;)
Dorian, I still don't understand what are you talking about. Neither of
the two is a part of the mod_perl 2 API. Perhaps if you show us the error
message you are getting it'll be more clear.
--
_
same issue, now with a function that exists. ;)
13 matches
Mail list logo