Re: [PATCH] tcp: set SPLICE_F_NONBLOCK after first buffer has been spliced

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Max Kellermann
Date: Thursday, November 5, 2009 - 6:23 am

On 2009/11/05 12:21, Eric Dumazet <eric.dumazet@gmail.com> wrote:

From the select() manpage: "those in writefds will be watched to see
if a write will not block"

From the poll() manpage: "Writing now will not block."

This looks unambiguous to me, and contradicts with your thesis.  Can
you provide sources?

What is your interpretation of the guarantees provided by select() and
poll()?  Which byte count is "ok" to write after POLLOUT, and how much
is "too much"?  How does the application know?


I understand your patch, but I don't understand the conflict with my
patch.  Can you describe a breakage caused by my patch?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] tcp: set SPLICE_F_NONBLOCK after first buffer ..., Max Kellermann, (Thu Nov 5, 6:23 am)