Re: UDP recvmsg blocks after select(), 2.6 bug?

Martijn Sipkema
2004-10-07T09:59:48Z

From: "David S. Miller" <davem@davemloft.net>
Sent: Thursday, October 07, 2004 01:29

> On Thu, 7 Oct 2004 02:19:37 +0200
> Olivier Galibert <galibert@pobox.com> wrote:
>
> > On Wed, Oct 06, 2004 at 04:35:21PM -0700, David S. Miller wrote:
> > > On Wed, 6 Oct 2004 22:06:08 +0200
> > > Olivier Galibert <galibert@pobox.com> wrote:
> > >
> > > > On Wed, Oct 06, 2004 at 12:43:27PM -0700, Hua Zhong wrote:
> > > > > How hard is it to treat the next read to the fd as NON_BLOCKING, even if
> > > > > it's not set?
> > > >
> > > > Programs don't expect EAGAIN from blocking sockets.
> > >
> > > That's right, which is why we block instead.
> >
> > Programs don't expect a read to block after a positive select either,
> > so it doesn't really help.
>
> It absolutely does help the programs not using select(), using
> blocking sockets, and not expecting -EAGAIN.

Both returning EAGAIN and blocking are not POSIX compliant. Returning EIO
from blocking sockets is an option. Another option would be to have select()
check the data so that when it returns it can guarantee available data. This would
not affect performance of recvmsg() without using select().

--ms