Message-ID: <417744FD.1000008@zytor.com>
Date: Wed, 20 Oct 2004 22:11:25 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Chris Friesen <cfriesen@nortelnetworks.com>
CC: Michael Clark <michael@metaparadigm.com>, linux-kernel@vger.kernel.org
Subject: Re: UDP recvmsg blocks after select(), 2.6 bug?
References: <20041016062512.GA17971@mark.mielke.cc> <MDEHLPKNGKAHNMBLJOLKMEONPAAA.davids@webmaster.com> <20041017133537.GL7468@marowsky-bree.de> <cl6lfq$jlg$1@terminus.zytor.com> <4176DF84.4050401@nortelnetworks.com> <4176E001.1080104@zytor.com> <41772674.50403@metaparadigm.com> <417736C0.8040102@zytor.com> <417743EF.90604@nortelnetworks.com>
In-Reply-To: <417743EF.90604@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 971
Lines: 29

Chris Friesen wrote:
> H. Peter Anvin wrote:
> 
>> The whole point is that it doesn't break the *documented* interface.
> 
> 
> In my view (and apparently others, as has been verified in current apps 
> using blocking sockets), current behaviour *does* break the documented 
> interface.
> 
> The man page for select says:
> 
> "Those  listed  in  readfds  will  be watched  to  see if characters 
> become available for reading (more precisely, to see if a read will not 
> block..."
> 
> If I'm the only one touching the socket, select returns with it 
> readable, and I block when calling recvmsg, then by definition that 
> behaviour does not match the documented interface.
> 

I'm talking about returning -1, EIO.

	-hpa
-
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/