Date: Thu, 14 Nov 1996 22:14:34 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: terry@lambert.org (Terry Lambert) Cc: jdp@polstra.com, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG Subject: Re: Sockets question... Message-ID: <199611150414.WAA26986@brasil.moneng.mei.com> In-Reply-To: <199611150112.SAA25075@phaeton.artisoft.com> from "Terry Lambert" at Nov 14, 96 06:12:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611150414.WAA26986>