Subject: Re: Bittorrent package and 'broken libc' claim
To: None <firstname.lastname@example.org>
From: Joerg Sonnenberger <email@example.com>
Date: 08/06/2005 17:18:51
On Sat, Aug 06, 2005 at 02:08:58PM +1200, Dave Sainty wrote:
> Joerg Sonnenberger writes:
> > > The optional bufsize argument specifies the file's desired buffer
> > > size: 0 means unbuffered, 1 means line buffered, any other positive
> > > value means use a buffer of (approximately) that size. A negative
> > > bufsize means to use the system default, which is usually line
> > > buffered for tty devices and fully buffered for other files. If
> > > omitted, the system default is used.
> > Ah! I've seen this problem on DragonFly too. Now it makes perfect sense.
> > Turning off buffering means a few things in the BSD libc:
> > (a) Reads are done with a buffer size of 1. That might arguable be a bug
> > for fread() or not, it's hard to say. I'm investigating.
> > (b) All open FILEs are fflushed before reading from such a file.
> > (c) Certain IO routines are checking for '\n' and handling it specially.
> I'd guess that the reason for (a) is to support (c)?
That's one reason. The other is simply that doing reads of 1 byte each
are the simplest way to use the same algorithm for buffered and
not-buffered operation :-)
> But if that's the case, it probably is an inefficiency to break
> block-fread()'s down into single-byte reads.
Yes, I think so.
> Perhaps it would be better to train fread() to read directly into the
> passed buffer, rather than repeatedly call __srefill() and copy the
> buffer - which in the unbuffered case is a 1-byte buffer.
That was exactly my thought. The question is how the various stdio
> Though one has to wonder what the justification for using stdio for
> purely unbuffered access is... Maybe it's a Python programmer thing
The Python file object is using stdio by default. That's fine as long as
you do what every normal program does -- namely using buffered IO.