Date: Thu, 14 Nov 1996 18:12:13 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG Subject: Re: Sockets question... Message-ID: <199611150112.SAA25075@phaeton.artisoft.com> In-Reply-To: <199611150002.QAA10843@austin.polstra.com> from "John Polstra" at Nov 14, 96 04:02:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Are you checking the return value from write() to make sure it actually > > > thinks that N bytes were _written_? > > > > > *sigh* > > 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. 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. 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. 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). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611150112.SAA25075>