Charles-François Natali added the comment: >> A useful parameter instead would be to support sending only part of the file, >> so adding a count argument. > > Have you read my patch? This is already provided by the "offset" parameter.
Of course I read your patch ;-) I mean I'd like a parameter for the offset, and another one for the number of bytes to send, like in Java's version (and sendfile(), see below). >> I really don't like the blocksize argument. >> I've *never* seen code which explicitly uses a blocksize > > Both sendfile() and TransmitFile provide a "blocksize" parameter for very > good reasons therefore it seems natural that an API built on top of them > exposes the same parameter as well. No, they expose a *count* parameter: http://linux.die.net/man/2/sendfile """ ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); count is the number of bytes to copy between the file descriptors. """ You're mixing up blocksize, which is the maximum number of bytes to transfer in one syscall and only makes sense in the context of repeated syscalls, and count, which is the total amount of data you want the function to transfer. No sensible sendfile-like API exposes a maximum "blocksize" to send at once, since the goal is to limit copies and system calls: you just pass a source and destination FD, a starting offset, and a number of bytes to transfer, and the syscall takes care of the rest. Here, you basically implement sendall() on top of sendfile() (in pseudo-code, using a buffer instead of a file and not taking into account short writes but the idea if the same): while <remaining data to send>: socket.sendfile(data[offset:offset+chunksize) The way it's supposed to be used is simply: socket.sendfile(data[offset:offset+count]) That's how everyone one uses sendfile(), that's how Java exposes it, and that's IMO how it should be exposed. To sum up, I think there's a fundamental confusion between blocksize and count in this API: that's what I've been saying since the beginning of this thread: if you disagree, that's OK, I just want to make sure we're talking about the same thing ;-) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17552> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
