Hi Richard, On Fri, 19 Jun 2020 at 14:44, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Thu, Jun 18, 2020 at 12:42:55PM -0700, Jacob Keller wrote: > > > So it is a bug if poll() wakes up the process for data availability on a > > > socket's receive queue, and then recvmsg(), called immediately > > > afterwards, goes to sleep trying to retrieve it. > > Yes. > > > Makes sense. Using MSG_DONTWAIT seems reasonable since we already know > > there should be data available. > > I disagree on this point. There are (at least) three ways to avoid > blocking on receive. > > 1. poll() first. The guarantees data are available, and for SDGAM > sockets those data comprise at least on message. > > 2. use the MSG_DONTWAIT flag > > 3. set the SO_RCVTIMEO socket option > > This patch would mix methods 1 and 2. I understand that it still > works with the DONTWAIT, but it sets a bad example. I want this > program to be an example of correct programming patterns. Our > industry has plenty enough guess work and sloppy copy and paste as it > is. > > Thanks, > Richard
Could you please give a concrete example of why it isn't desirable for MSG_DONTWAIT to be specified on a socket where data availability has been previously confirmed through poll()? I'm not sure what the patch has to do with the industry having "plenty enough guess work and sloppy copy and paste as it is". Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
