This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients eric.araujo, giampaolo.rodola, neologix, pitrou, rosslagerwall
Date 2013-03-07.15:07:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2bEbip-mX-5wU9JG5=iQgiCE9jnOyfkuRritSWws_qFA@mail.gmail.com>
In-reply-to <1362667872.18.0.127575309336.issue13564@psf.upfronthosting.co.za>
Content
> It's necessary because sendfile() can fail with EAGAIN.

It can fail with EAGAIN if the input FD is non-blocking, exactly like
the current implementation which calls fp.read(). Furthermore, since
sendfile actually supports only regular file and regular files don't
support non-blocking I/O, it's unlikely to ever happen.

> As for your "blocksize = filesize" argument I changed my opinion: despite being less CPU consuming we might incur into problems if that number is too big.  'count' parameter on Linux, for example, is expected to be an unsigned int.

'count'  is size_t, like for mmap() and any other function accepting a
length, so nothing wrong can happen.
A platform which would have a sendfile prototype which doesn't support
sending a complete file at once would be completely broken...
History
Date User Action Args
2013-03-07 15:07:41neologixsetrecipients: + neologix, pitrou, giampaolo.rodola, eric.araujo, rosslagerwall
2013-03-07 15:07:41neologixlinkissue13564 messages
2013-03-07 15:07:41neologixcreate