Eric Sunshine <sunsh...@sunshineco.com> writes:
>> while (1) {
>> nr = read(fd, buf, len);
>> - if ((nr < 0) && (errno == EAGAIN || errno == EINTR))
>> - continue;
>> + if (nr < 0) {
>> + if (errno == EINTR)
>> + continue;
>> + if (errno == EAGAIN || errno == EWOULDBLOCK) {
>> + struct pollfd pfd;
>> + int i;
>> + pfd.events = POLLIN;
>> + pfd.fd = fd;
>> + i = poll(&pfd, 1, 100);
>
> Why is this poll() using a timeout? Isn't that still a busy wait of
> sorts (even if less aggressive)?
Good point. If we _were_ to have this kind of "hiding issues under
the rug and continuing without issues" approach, I do not think we
would need timeout for this poll(2). The caller accepted that it is
willing to wait until we read up to len (which is capped, though) by
not calling the nonblocking variant.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
