Re: [PATCH] recvmmsg.2 Updated timeout documentation

On 12/23/2012 07:30 PM, Michael Kerrisk (man-pages) wrote:

Elie,

quoted

In any case, when operating in non-blocking mode, the timeout is taken into
account, which could mean that recvmmsg() returns while data is still
available (which was not clearly stated). (Combination of much data to
copy and a very sharp timeout).

Can you say more about what you see/understand with nonblocking mode.
I don't understand what you mean here (and it doesn't fit with what I
am seeing on testing). Nonblocking mode should, I believe, always mean
an immediate return, regardless of any timeout.

It's just cosmetics really, now they state that:
"
A nonblocking call reads as many messages as are available (up to the 
limit specified by vlen) and returns immediately.
"

Suppose that you are operating in non-blocking mode, the timeout is set 
to one nanosecond (yeah, living on the edge), and vlen is an insane 
large number (say a thousand) whilst assuming that data is available to 
be received. The text from the manpage says that you will return if the 
available data is depleted or if you have read 'vlen' buffers. So it 
means there's a 'faster than timeout' possible.

What the kernel implementation actually does (simplified, and ignoring 
WAITFORONE) is:

while(datagrams < vlen) {
   err = recvmsg()
   if (err) break;
   if (timeout) break;
   datagrams++
}

Both in non-blocking/blocking mode, and I think the manpage should make 
the three possible exit scenario (vlen, timeout, err) clear in both 
blocking and non-blocking mode.

gr
E.

-- 
Elie De Brauwer

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html