Giampaolo Rodola' added the comment:

> 'count'  is size_t, like for mmap() and any other function accepting a 
> length, so nothing wrong can happen.

Then why 'offset' and 'count' parameters have a different data type?

Linux: 
sendfile(..., off_t *offset, size_t count);

Solaris:
sendfile(..., off_t *off,    size_t len);

HP-UX:
sendfile(..., off_t offset,  bsize_t nbytes);


> A platform which would have a sendfile prototype which doesn't support
> sending a complete file at once would be completely broken...

You can't send a complete file at once in the first place unless it's very 
small. 
The usual way to send a file is chunk by chunk, so it wouldn't surprise me if 
sendfile() prototype does not support the use case you're describing.
Anyway, Antoine's suggestion makes sense to me: it's probably ok to just use a 
big value and be done with it.
16MB looks a little bit too much to me as the maximum amount of bytes sent per 
call is a lot less than 1MB, but even then it would probably be ok.


>> It's necessary because sendfile() can fail with EAGAIN.
> It can fail with EAGAIN if the input FD is non-blocking

It will. Try it yourself.


> Furthermore, since sendfile actually supports only regular file and regular 
> files don't support non-blocking I/O, it's unlikely to ever happen.

EAGAIN is caused by the socket fd not being ready yet, not the file fd.
Please try the patch before making such assumptions. We're going OT here.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13564>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to