You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by jo...@apache.org on 2006/05/04 18:17:36 UTC
svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Author: jorton
Date: Thu May 4 09:17:36 2006
New Revision: 399750
URL: http://svn.apache.org/viewcvs?rev=399750&view=rev
Log:
* network_io/unix/sendrecv.c [__linux__] (apr_socket_sendfile): Limit
each call to 2Gb.
Modified:
apr/apr/trunk/network_io/unix/sendrecv.c
Modified: apr/apr/trunk/network_io/unix/sendrecv.c
URL: http://svn.apache.org/viewcvs/apr/apr/trunk/network_io/unix/sendrecv.c?rev=399750&r1=399749&r2=399750&view=diff
==============================================================================
--- apr/apr/trunk/network_io/unix/sendrecv.c (original)
+++ apr/apr/trunk/network_io/unix/sendrecv.c Thu May 4 09:17:36 2006
@@ -269,6 +269,14 @@
#else
off_t off = *offset;
+
+ /* Multiple reports have shown sendfile failing with EINVAL if
+ * passed a >=2Gb count value on some 64-bit kernels. It won't
+ * noticably hurt performance to limit each call to <2Gb at a
+ * time, so avoid that issue here: */
+ if (sizeof(off_t) == 8 && *len > INT_MAX) {
+ *len = INT_MAX;
+ }
#endif
if (!hdtr) {
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
> > Perhaps it was lost a couple of posts ago, but Joe's INT_MAX usage is
> > inside a Linux block and is needed only for a Linux "nuance".
>
> cool, thanks! (And yes I was thinking of S370's running SuSe 8 or other
> variants in 31 bit addressing mode; glad that math doesn't change)
I was confused; for no good reason "390" triggers "MVS", "OS/390", and
"z/OS" and it is "zSeries" which triggers "Linux". I guess I'm not
in the target market and don't see enough marketing materials. (Give
me a quiet Dxxx low-end server box or two and an expensive Thinkpad
and I'm happy.)
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> Perhaps it was lost a couple of posts ago, but Joe's INT_MAX usage is
> inside a Linux block and is needed only for a Linux "nuance".
cool, thanks! (And yes I was thinking of S370's running SuSe 8 or other
variants in 31 bit addressing mode; glad that math doesn't change)
Bill
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by Jeff Trawick <tr...@gmail.com>.
On 5/4/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Colm MacCarthaigh wrote:
> > Can we be sure that INT_MAX == 2GB ? What about I64 platforms like
> > Alpha?
>
> Signed int max would be 30^2 on IBM 390 native architectures, right Jeff?
You're thinking of pointers in the ever popular 31-bit addressing
mode, where the high order bit isn't significant. No such games with
ints, which don't vary in size between 31-bit addressing mode and
64-bit addressing mode:
/usr/include/limits.h: #define INT_MAX 2147483647
/usr/include/limits.h: #define UINT_MAX 4294967295U
--/--
Perhaps it was lost a couple of posts ago, but Joe's INT_MAX usage is
inside a Linux block and is needed only for a Linux "nuance".
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Colm MacCarthaigh wrote:
> Can we be sure that INT_MAX == 2GB ? What about I64 platforms like
> Alpha?
Signed int max would be 30^2 on IBM 390 native architectures, right Jeff?
Bill
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by Joe Orton <jo...@redhat.com>.
On Thu, May 04, 2006 at 05:28:37PM +0100, Colm MacCarthaigh wrote:
> Can we be sure that INT_MAX == 2GB ?
On all 64-bit Linux platforms, yes.
Re: svn commit: r399750 - /apr/apr/trunk/network_io/unix/sendrecv.c
Posted by Colm MacCarthaigh <co...@stdlib.net>.
Can we be sure that INT_MAX == 2GB ? What about I64 platforms like
Alpha?
On Thu, May 04, 2006 at 04:17:36PM -0000, jorton@apache.org wrote:
> ==============================================================================
> --- apr/apr/trunk/network_io/unix/sendrecv.c (original)
> +++ apr/apr/trunk/network_io/unix/sendrecv.c Thu May 4 09:17:36 2006
> @@ -269,6 +269,14 @@
>
> #else
> off_t off = *offset;
> +
> + /* Multiple reports have shown sendfile failing with EINVAL if
> + * passed a >=2Gb count value on some 64-bit kernels. It won't
> + * noticably hurt performance to limit each call to <2Gb at a
> + * time, so avoid that issue here: */
> + if (sizeof(off_t) == 8 && *len > INT_MAX) {
> + *len = INT_MAX;
> + }
> #endif
>
> if (!hdtr) {
>
>
>
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net