Charles-François Natali added the comment: > If only one byte is available, recv(4096) should simply return a partial > result.
Of course, but how do you know if there's data left to read without calling select() again? It's much better to call read() until you get EAGAIN than calling select() between each read()/write() call. > Wouldn't you just get a partial write (assuming an AF_INET, SOCK_STREAM > socket)? For SOCK_STREAM, yes, not for SOCK_DGRAM (or for a pipe when trying to write more than PIPE_BUF, although I guess any sensible implementation doesn't report the pipe write ready if there's less than PIPE_BUF space left). > It's a design decision and a huge performance win. It's one of the areas > where POSIX read in its strictest form cripples your performance. Yes, he's referring to the fact that there are cases where you could avoid some spurious notifications, but that would incur a performance hit: that's exactly the same rationale behind condition variables spurious wakups: since the user-code must be prepared to handle spurious notifications, let's take advantage of it. But there are been various fixes in the past years to avoid spurious notifications in epoll() for example, because while they allow certain optimizations in the kernel, spurious wakeups can cost to user-level applications... I'm 99% sure that Linux isn't the only OS allowing spurious wakeups, since it's essentially an unsolvable issue (temporary shortage of buffer, or the example given by Alan Cox of a pipe with two readers...). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16507> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com