Date: Thu, 14 Nov 1996 20:51:54 -0800 From: John Polstra <jdp@polstra.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: scrappy@ki.net, hackers@FreeBSD.org Subject: Re: Sockets question... Message-ID: <199611150451.UAA12629@austin.polstra.com> In-Reply-To: Your message of "Thu, 14 Nov 1996 21:53:09 CST." <199611150353.VAA26930@brasil.moneng.mei.com> References: <199611150353.VAA26930@brasil.moneng.mei.com>
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. ... > I don't recall anybody specifying which was the case... maybe I forgot. > > Besides, I believe that good coding practice suggests that such things > should be checked for unless you are REALLY concerned about performance > and can NOT afford the hit of an extra compare and branch... Oh sure, I agree 100% that you should always check the return value. I'd take your statement a step further and say that you can _never_ not affort the hit of an extra compare and branch. My argument was strictly from the perspective of finding an explanation for the apparent data loss that scrappy was seeing. I was arguing that, if the sending socket was in blocking mode, it would never return a short count and therefore couldn't explain the "lost" data in this case. I didn't mean it to sound as though I was recommending sloppy programming practices. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611150451.UAA12629>