3 ms·
> will only block if you request more data then is available in the buffer Sadly, that's not true on Linux. According to the man page[1]: > Under Linux, selec
by moefh 9y ago
> will only block if you request more data then is available in the buffer
Sadly, that's not true on Linux. According to the man page[1]:
> Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded.
(I assume the same is true of pselect(), described in the same page, although it doesn't specifically say so)
So the rule is: don't trust select(), always use O_NONBLOCK if you don't want to block.
[1] http://man7.org/linux/man-pages/man2/select.2.html http://man7.org/linux/man-pages/man2/select.2.html
- DSMan195276 9y agoHuh, that's interesting. That seems weird to me, but I suppose it could technically make things faster assuming things like checksum failures are rare. I suppose the reason might be that they can mark the socket while still in the interrupt handler, but I haven't read those parts of the kernel close enough to know if they actually do such a thing. But either way, I would agree, if you don't want blocking then just use O_NONBLOCK, it's the intended way and it's the best way.