Date: Fri, 15 Nov 1996 13:54:58 PST From: Bill Fenner <fenner@parc.xerox.com> To: fenner@parc.xerox.com, terry@lambert.org Cc: hackers@freebsd.org, jdp@polstra.com, scrappy@ki.net Subject: Re: Sockets question... Message-ID: <96Nov15.135501pst.177557@crevenia.parc.xerox.com>
next in thread | raw e-mail | index | archive | help
Terry: >Bill: > Terry: >> >So at the "read" interface, you *can* count on it arriving in the >> >same sized chunks as you wrote it >> >> No, you can *never* count on that, since non-blocking reads from a stream >> socket return as much data as is available, which could be less than you >> asked for. See soo_read() (or soo_rw() in earlier BSD's) and soreceive(). > >By default, the sockets are blocking. You have to go out of your >way to make them non-blocking (ie: loading the gun before you can shoot >yourself in the foot). Terry, STOP SPECULATING. Look at the code. soo_read() is what is called by the read system call, and it calls soreceive(). soreceive() returns whatever is waiting, up to what is requested, unless you set MSG_WAITALL. soo_read() doesn't set MSG_WAITALL, so the semantics of read() on a blocking socket is to return as much data is waiting, up to the amount that was requested. >But on a blocking socket, it doesn't make sense to have to issue multiple >system calls to read chunks of a whole message when you aren't going to >do anything with it until all the reads have been satisfied? The CSRG apparently felt otherwise. Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96Nov15.135501pst.177557>