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

[Martijn Sipkema]

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

> On Thu, 7 Oct 2004 02:19:37 +0200
> Olivier Galibert <galibert@xxxxxxxxx> 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@xxxxxxxxx> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/