On Aug 6, 2012, at 10:56 PM, Roberto De Ioris <[email protected]> wrote:

Can you try with a stable/recent uWSGI release ? sendfile support was
rewritten before 1.0, so i suspect it may be the problem here.

sendfile() is 64bit friendly so you should not have problems from a kernel
point of view.

I got the same behavior with 1.2.4 (64bit) and 1.3-snapshot2. Poking around with gdb showed that sendfile() was getting all the right parameters but stopping at the 2GB mark with a return value of the number of bytes sent. Reading the Linux manpage, it makes no guarantee that the number of sent bytes is the same number of bytes passed as an argument, and sendfile() looks to behave just like write() even though it's not explicitly documented so. Simply re-calling sendfile resumes the transfer at the right spot. The kernel on this box is 3.0.0-14, if it matters.

I've attached a patch against 1.3-snapshot2 that repeatedly calls sendfile() until an error occurs or the total number of bytes make it through, and it worked for my test case. It also appears to line up with the head of the source tree; feel free to use it if the patch matches the project's style.

This code section is #IFDEFed for Solaris as well as Linux, but I don't have access to a Solaris machine or even rightly know if Solaris is still a thing, but I don't think it should break Solaris in any case. I wouldn't dare hazard a guess if this type of behavior affects any other system, I hadn't known about just how divergent sendfile() was on various platforms until seeing the complexity in sendfile.c.

Best,
-Charlie

Attachment: sendfile-linux-2gig.patch
Description: Binary data

_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Reply via email to