Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261151AbTFJSy1 (ORCPT ); Tue, 10 Jun 2003 14:54:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261928AbTFJSyK (ORCPT ); Tue, 10 Jun 2003 14:54:10 -0400 Received: from 34.mufa.noln.chcgil24.dsl.att.net ([12.100.181.34]:5871 "EHLO tabby.cats.internal") by vger.kernel.org with ESMTP id S261151AbTFJSvo (ORCPT ); Tue, 10 Jun 2003 14:51:44 -0400 Content-Type: text/plain; charset=US-ASCII From: Jesse Pollard To: Krzysztof Halasa , Timothy Miller Subject: Re: select for UNIX sockets? Date: Tue, 10 Jun 2003 14:04:41 -0500 X-Mailer: KMail [version 1.2] Cc: David Schwartz , linux-kernel@vger.kernel.org References: <3EE5DE7E.4090800@techsource.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <03061014044103.06462@tabby> Content-Transfer-Encoding: 7BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2794 Lines: 72 On Tuesday 10 June 2003 09:21, Krzysztof Halasa wrote: > Timothy Miller writes: > > If you were to use blocking writes, and you sent too much data, then > > you would block. If you were to use non-blocking writes, then the > > socket would take as much data as it could, then return from write() > > with an indication of how much data actually got sent. Then you call > > select() again so as to wait for your next opportunity to send some > > more of your data. > > This is all true in general but in this particular case of unix datagram > sockets select (poll) is just buggy. Ahh no. The following is from Solaris 2.8 manpage on poll: The poll() function supports regular files, terminal and pseudo-terminal devices, STREAMS-based files, FIFOs and pipes. The behavior of poll() on elements of fds that refer to other types of file is unspecified. The poll() function supports sockets. A file descriptor for a socket that is listening for connec- tions will indicate that it is ready for reading, once con- nections are available. A file descriptor for a socket that is connecting asynchronously will indicate that it is ready for writing, once a connection has been established. As in: ALWAYS ready to write as soon as a connection is made. It can still block on a write if the amount to write is larger than the buffer available. Nothing is said about the AMOUNT that can be written (though with most FIFOs/pipes the limit is ~ 4K, though not guaranteed since other writers may fill it between the poll and the write. The select function (3c): The select() function supports regular files, terminal and pseudo-terminal devices, STREAMS-based files, FIFOs and pipes. The behavior of select() on file descriptors that refer to other types of file is unspecified. And the following on it's use on sockets: A file descriptor for a socket that is listening for connec- tions will indicate that it is ready for reading, when con- nections are available. A file descriptor for a socket that is connecting asynchronously will indicate that it is ready for writing, when a connection has been established. as in "READY for writing", not that it won't block when you DO write. (Also "READY for reading", not that it won't block when you DO read.) You've been lucky to have relatively idle systems or large memory systems. I suspect you actually were blocking, just not for very long. - 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/