> 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 > >
Looks like this behaviour for blocking sockets is Linux/Solaris only. I will apply your patch as-is Thanks -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
