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

["Martijn Sipkema" <martijn@entmoot.nl>]

From: "Adam Heath" <doogie@debian.org>
> On Thu, 7 Oct 2004, Alan Cox wrote:
> 
> > On Iau, 2004-10-07 at 15:07, Martijn Sipkema wrote:
> > > > Much can change between the select() and recvmsg - things outside of
> > > > kernel control too, and it's long been known.
> > >
> > > There is no change; the current implementation just checks the validity of
> > > the data in the recvmsg() call and not during select().
> >
> > The accept one is documented by Stevens and well known. In the UDP case
> > currently we could get precise behaviour - by halving performance of UDP
> > applications like video streaming. We probably don't want to  because we
> > can respond intelligently to OOM situations by freeing the queue if we
> > don't enforce such a silly rule.
> 
> Also, pkts could be dropped even for TCP sockets.  TCP will cause the pkt to
> be retransmitted, but while that is occuring, the read that was prompted by
> the select will still block.
> 
> So, any app that does not use O_NONBLOCK is broken, if they assume that a
> successful select will indicate a nonblocking read/recvmsg.

Aaargh... I'm going to shut up about this now, because this is clearly going
nowhere, but you are saying that any application that expects behaviour as
defined in POSIX is broken, and that bothers me..


--ms