www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From traw...@apache.org
Subject Re: os-aix/7418: Incorrect reporting of bytes sent by send_file()
Date Thu, 15 Mar 2001 18:48:56 GMT
[In order for any reply to be added to the PR database, you need]
[to include <apbugs@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or      ]
["Re: general/1098:").  If the subject doesn't match this       ]
[pattern, your message will be misfiled and ignored.  The       ]
["apbugs" address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]


Synopsis: Incorrect reporting of bytes sent by send_file()

Comment-Added-By: trawick
Comment-Added-When: Thu Mar 15 10:48:54 PST 2001
Comment-Added:
>From your patch, I suspect that you misundersood the intended
semantics of apr_sendfile().  Hopefully my follow-up questions
and/or comments below will help sort out where the misunderstanding
may lie.

>The apr_sendfile() function in the srclib/apr/network_io/unix/sendrecv.c 
>only reports the number of bytes sent by the last call to send_file.  

What do you think it should report?

>The code also only checks for a return code of -1, and not a return 
>code of 1 which indicates that send_file() was able to send part of 
>the data, but not all of it.

Why does apr_sendfile() care?  It merely needs to tell the caller
how much data was sent, and it knows by looking at the updated
parms.bytes_sent field.

>On AIX this results in a minor performance degradation since 
>Apache has to make multiple calls to the apr_sendfile() 
>function to send large files.  

The same is true of other routines which write on a socket.
We do not hang around inside APR write-to-the-network routines
until all data has been written.

Note that the socket used by Apache has been marked non-blocking.
We expect that multiple syscalls will be used to send large files.
In return, we are able to control when we give up on send_file()
and decide to drop the connection because of a timeout.

We *could* do the multiple-syscall repeat inside APR but have
not chosen to do so.

>However, on a version of one of our operating systems currently under 
>developement (I could tell you which one, but then I'd have to kill 
>you :)) it causes Apache to fail to send files larger than twice 
>the send buffer size.

Maybe if you can answer my questions above I'll understand.
Is there a bug in the code which calls apr_sendfile() which
prevents it from being able to call apr_sendfile() enough
times?

About the future AIX change: Does this mean that OS/390 and AIX 
can no longer use the same apr_sendfile() implementation at 
that point?  That would suck.

I look forward to your update.


Mime
View raw message