From: "David Schwartz" <davids@webmaster.com>
To: "MarKol" <markol4@wp.pl>, <linux-kernel@vger.kernel.org>
Subject: RE: select for UNIX sockets?
Date: Fri, 6 Jun 2003 17:14:33 -0700
Message-ID: <MDEHLPKNGKAHNMBLJOLKMEOBDHAA.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
In-Reply-To: <002f01c32c26$18c85f30$010110ac@uran238>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2359
Lines: 57


> Since I was an initiator of this topic on one of the Polish Linux groups
> I'd like to explain some issues. We've been porting some larger piece of
> software from Solaris to Linux and problem has arisen. Below is
> corrected
> example (with errors checking after function calls), where isolated
> problem
> is presented. I hope this will cut off any suggestions that some of
> function
> calls return errors which aren't detected and handled.
>
> An experiment shows that there is no error occurrences while running
> these
> examples on Linux and sender blocks on sendto() (after sending
> _successfully_
> some datagrams to the receiver) when select() returns with ready to
> write descriptor.
>
> The same example works _correct_ on Solaris and QNX (sender blocks on
> select() call and _never_ on sendto() ).
>
> Question is:
> Am I doing something wrong or maybe there is a bug in select() function
> under Linux?

	You are doing something wrong. You are using 'select' along with blocking
I/O operations. You can't make bricks without clay. If you don't want to
block, you must use non-blocking socket operations. End of story.

	Just because 'select' indicates a write hit, you are not assured that some
particular write at a later time will not block. Past performance does not
guarantee future results.

	Suppose, for example, a machine has two network interfaces. One is very
busy, queue full, and one is totally idle, queue empty. What do you think
'select' for write on an unconnected UDP socket should do? If you say it
should block, then it can block forever even if there's plenty of buffer
space on the network card you were going to send to. So, it can't block, it
must indicate writability.

	Now, tell me what a blocking UDP write should do if the buffer is full.
Should it return success but drop the packet silently? Does that seem right
to you?

	You have any number of sane choices. My suggestion is that you make the
socket non-blocking and treat an EWOULDBLOCK return as equivalent to
success. You can additionally take it as a hint that the packet will be as
if it was dropped.

	DS


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