Date: Fri, 15 Nov 1996 10:06:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jdp@polstra.com (John Polstra) Cc: terry@lambert.org, scrappy@ki.net, jgreco@brasil.moneng.mei.com, hackers@FreeBSD.ORG Subject: Re: Sockets question... Message-ID: <199611151706.KAA26239@phaeton.artisoft.com> In-Reply-To: <199611150127.RAA11283@austin.polstra.com> from "John Polstra" at Nov 14, 96 05:27:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). > > This is most certainly not guaranteed by the documentation. From > read(2): > > The system guarantees to read the number of bytes requested > if the descriptor references a normal file that has that many > bytes left before the end-of-file, but in no other case. Then what use is the thing? How do I read into a structure on a machine that demands aligned data access? Specifically, if it's allowed to read 3 bytes of an integer value, and you are suppossed to reissue a read for the third byte (this I find hard to believe!), how do you access this data area atomically? No, I understand that the implementation *allows* this type of behavior for non-blocking I/O, and device I/O on non-blocking devices (like the bit-set mouse device), and for tty devices where the read count exceeds the vmin for more than vtime, but nothing would work at all if you couldn't issue a read for n bytes that didn't complete until you *got* n bytes. 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?199611151706.KAA26239>