Reply-To: <hzhong@cisco.com>
From: "Hua Zhong" <hzhong@cisco.com>
To: "'Chris Friesen'" <cfriesen@nortelnetworks.com>,
       "'David S. Miller'" <davem@davemloft.net>
Cc: <aebr@win.tue.nl>, <joris@eljakim.nl>, <alan@lxorguk.ukuu.org.uk>,
       <linux-kernel@vger.kernel.org>
Subject: RE: UDP recvmsg blocks after select(), 2.6 bug?
Date: Wed, 6 Oct 2004 13:26:29 -0700
Organization: Cisco Systems
Message-ID: <003a01c4abe2$c3431ad0$b83147ab@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <4164530F.7020605@nortelnetworks.com>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1186
Lines: 31

>  From what Andries posted, we can't block.  If select says 
> its readable, we can "return data, an  end-of-file  indication, 
> or  an  error other than one indicating that it is  blocked".

Arrrrgh..I misread it as "or an error indicating that it is blocked"..

So treating it simply as NON_BLOCKING isn't right.

> Hmm...no easy solution then.
> 
> In any case, the current behaviour is not compliant with the 
> POSIX text that Andries posted.  Perhaps this should be 
> documented somewhere?
> Alternately, how about having the recvmsg() call return a 
> zero, and (if appropriate) the length of the name set to zero?  This 
> appears to comply with the man page for recvmsg().

If it's a read, returning zero means end-of-file. Not sure what it means 
when recvmsg returns zero..But is this just the problem of UDP or 
recvmsg? I doubt it.

So I guess the easiest solution is just admit Linux select 
isn't posix compliant.

> Chris

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