From owner-freebsd-hackers Thu Nov 14 20:54:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12298 for hackers-outgoing; Thu, 14 Nov 1996 20:54:47 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA12293 for ; Thu, 14 Nov 1996 20:54:40 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id UAA12629; Thu, 14 Nov 1996 20:51:54 -0800 (PST) Message-Id: <199611150451.UAA12629@austin.polstra.com> To: Joe Greco cc: scrappy@ki.net, hackers@FreeBSD.org Subject: Re: Sockets question... 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> Date: Thu, 14 Nov 1996 20:51:54 -0800 From: John Polstra 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. ... > 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