tags 700529 fixed-upstream thanks On Thu, Feb 14, 2013 at 12:38 AM, Marc Lehmann <debian-report...@plan9.de> wrote: > Package: manpages-dev > Version: 3.40-0.1 > Severity: minor > > > The read(2) manpage (possibly others) contains this confusing paragraph in > the NOTES section: > > Many file systems and disks were considered to be fast enough that > the implementation of O_NONBLOCK was deemed unnecessary. So, > O_NONBLOCK may not be available on files and/or disks. > > However, this can neither be true, nor is there reasonable semantics for > O_NONBLOCK on files. The reason for this is that for O_NONBLOCK to make > sense, you need data to arrive on its own (pipe write on other side, tcp > packet received etc.). > > For files, there is no such source of data - while an implementatioon that > indeed only returned what it currently has in the the buffer cache is > theoretically feasible, no new data would arrive on its own, as the kernel > would need to know how much data to read, and from where, so programs > would effectively deadlock as there is no way to tell the kernel to read > more data for the next read (and there is no way to wait for more data, as > it would be for pipes and sockets with e.g. select). > > I would suggest simply deleting this paragraph, as it continues to confuse > people into thinking O_NONBLOCK semantics are possible with files.
Well, O_NONBLOCK does have meaningful semantics w.r.t. file locks. But, that doesn't seem to be what this paragraph is talking about, and I agree with you that it is confusing. I've removed it. Thanks for the report. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
