> 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...