Re: [PATCH] recvmmsg.2 Updated timeout documentation

[Elie De Brauwer <eliedebrauwer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 12/23/2012 07:30 PM, Michael Kerrisk (man-pages) wrote:
> Elie,
>
>> 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