From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Friesen Subject: Re: recvmmsg() timeout behavior strangeness Date: Wed, 09 Jan 2013 16:33:02 -0600 Message-ID: <50EDF01E.10709@genband.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Michael Kerrisk Cc: Arnaldo Carvalho de Melo , Caitlin Bestler , David Miller , netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chris Van Hoof , Clark Williams , Neil Horman , Arnaldo Carvalho de Melo , Andrew Grover , Elie De Brauwer , linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Steven Whitehouse , =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= List-Id: linux-man@vger.kernel.org On 12/23/2012 02:50 PM, Michael Kerrisk wrote: > If I understand correctly, the *intended* purpose of the timeout > argument is to set a limit on how long to wait for additional > datagrams after the arrival of an initial datagram. However, the > syscall behaves in quite a different way. Instead, it potentially > blocks forever, regardless of the timeout. Looking at the code, I think you're correct. The comments for a2e2725 say the timeout works like for ppoll(), where it is "an upper limit on the time for which poll() will block, in milliseconds." I wonder if we could play some games with sk->sk_rcvtimeo to accomplish this? Chris -- 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