Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: [patch] C implementation of $r->content + rfc on the name
From: "Philippe M. Chiasson" <gozer@cpan.org>
To: Stas Bekman <stas@stason.org>
Cc: dev@perl.apache.org
In-Reply-To: <3EC96175.7050607@stason.org>
References: <3EC34A08.2020400@stason.org>
	 <1053085699.4416.32.camel@shou.sg.ectoplasm.org>
	 <3EC81424.6010308@stason.org>
	 <1053311732.15766.5.camel@shou.sg.ectoplasm.org>
	 <3EC96175.7050607@stason.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="=-8A7MONWrudIWbQ9ygmtD"
Organization: 
Message-Id: <1053412613.17915.22.camel@shou.sg.ectoplasm.org>
Mime-Version: 1.0
Date: 20 May 2003 14:36:53 +0800

--=-8A7MONWrudIWbQ9ygmtD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2003-05-20 at 06:57, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>=20
> >>>Why not implement your own pflatten equivalent
> >>>
> >>>apr_status_t modperl_brigade_sv_flatten(pTHX_ apr_bucket_brigade *bb, =
SV
> >>>*sv) {
> >>>                                              =20
> >>>{
> >>>    apr_off_t actual;
> >>>    apr_size_t total;
> >>>    apr_status_t rv;
> >>>
> >>>    /* XXX: 1: triggers reads on unknown size buckets */
> >>>    apr_brigade_length(bb, 1, &actual);
> >>>    total =3D (apr_size_t)actual;
> >>>   =20
> >>>    return apr_brigade_flatten(bb, SvGROW(sv, total), &total);
> >>>}
> >>>
> >>>Something like that, to at least avoid allocating the storage twice.
> >>
> >>right, I've missed the _length API :(
> >=20
> >=20
> > And it should be used carefully, as to figure out the length of a
> > brigade, all buckets with unknown length (-1), i.e. network buckets,
> > will have to be read first (i.e. network reads) before their size can b=
e
> > assessed. That's why there is a 1/0 flag in _length to specify if you
> > want the 'exact' size, or just the size of what's known.
>=20
> I thought that since this is an input stream, chances are that 99.9% of t=
he=20
> traffic will be plain HEAP buckets. POST data is always coming fully atta=
ched.=20
> So it should be safe to force using the length.

I didn't check the code, but I do seem to remember that
core_input_filter will insert a socket bucket (the tcp connection) in
the input chain.

And I would expect that callign apr_brigade_length on that with the '1'
flag could potentially result in a blocking call to apr_bucket_read if
apr_brigade_length is reading in APR_BLOCK_READ mode.

It does make sense in a way. If the data is coming from a slow client,
you'll need to read it all in before you can figure out what it's size
is.
> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
--=20
-- ------------------------------------------------------------------------=
-----
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634=
E37B)
http://gozer.ectoplasm.org/    F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3=
 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenio=
us.
perl -e'$$=3D\${gozer};{$_=3Dunpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$+=
+&&redo}'

--=-8A7MONWrudIWbQ9ygmtD
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+yc0FyzKhB4jDpaURAu0YAJ9PFVWDMkfrmtXfBqLjpHcqxqwtpACgwQkc
KeOThxHDpZJ2w+FJi/F5Wh4=
=6v0y
-----END PGP SIGNATURE-----

--=-8A7MONWrudIWbQ9ygmtD--