From owner-freebsd-hackers Thu Nov 14 20:19:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10402 for hackers-outgoing; Thu, 14 Nov 1996 20:19:01 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10393 for ; Thu, 14 Nov 1996 20:18:48 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA26986; Thu, 14 Nov 1996 22:14:35 -0600 From: Joe Greco Message-Id: <199611150414.WAA26986@brasil.moneng.mei.com> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Thu, 14 Nov 1996 22:14:34 -0600 (CST) Cc: jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG In-Reply-To: <199611150112.SAA25075@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 96 06:12:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Well now, wait a minute. As long as you haven't set the socket for > > non-blocking I/O, the write will always block until it's written the > > full N bytes that you asked for. In other words, the write will always > > return either -1 or N. Only if it's set up for non-blocking I/O can it > > return a short count. Writes are different from reads in this respect. > > The problem that is supposedly being addressed by looking at the bytes > written is knowing that the data will be available as a unit to the > reader. Wrong, Terry. The problem that is supposedly being addressed (and as the person who wrote the advice, I am telling you indisputably that this is what is being addressed) is that sometimes, people will forget that they are writing to a particular type of socket (such as {,non}blocking) and will inadvertently forget to check to see if all the data was written. In the case of a blocking socket, the penalty is minor, an extra compare and branch, most likely. In the case of a nonblocking socket, the test is mandatory. In the case of an indeterminate socket, the test is also mandatory - precisely BECAUSE you don't know. > There is no such guarantee. > > If you don't use non-blocking I/O, the read will block until the buffer > is full. Use blocking I/O, and you won't have the problem with the > reader returning before it should (or shouldn't). Otherwise the RPC > interfaces wouldn't work at all. I am not too sure that statement is true... but then I am a paranoid programmer, so I always define an xread() function guaranteed to do what I mean. Still, that bothers me... > Instead of making a non-blocking read for which "it's OK if no data > is available", use select() and only call a blocking read if the select > is true. And I think this is what I was looking for... If you have a blocking read, select() returns true on a FD because one byte is available, and you try a read(1000), will it block? I am reasonably certain that it will not - it will return the one byte. Ahhh. Yes. % man 2 read (SunOS version) Upon successful completion, read() and readv() return the number of bytes actually read and placed in the buffer. The Sun Release 4.1 Last change: 21 January 1990 1 READ(2V) SYSTEM CALLS READ(2V) system guarantees to read the number of bytes requested if the descriptor references a normal file which has that many bytes left before the EOF (end of file), but in no other case. Key words, "but in no other case".. > Any hang problems from fragmentation, etc. that happen after that are > a result of you not marchalling your interfaces properly (again, I > recommend the RPC code for examples). ... JG