From owner-svn-src-head@FreeBSD.ORG Sat Feb 16 13:26:24 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A08B28FA; Sat, 16 Feb 2013 13:26:24 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 6427FA54; Sat, 16 Feb 2013 13:26:24 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id C03D6358C2A; Sat, 16 Feb 2013 14:26:23 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 9EE062848C; Sat, 16 Feb 2013 14:26:23 +0100 (CET) Date: Sat, 16 Feb 2013 14:26:23 +0100 From: Jilles Tjoelker To: Bruce Evans Subject: Re: svn commit: r246824 - head/lib/libc/stdio Message-ID: <20130216132623.GA25333@stack.nl> References: <201302151044.r1FAi8rs010160@svn.freebsd.org> <20130216024443.N1029@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130216024443.N1029@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:26:24 -0000 On Sat, Feb 16, 2013 at 04:08:06AM +1100, Bruce Evans wrote: > On Fri, 15 Feb 2013, Jilles Tjoelker wrote: > > Log: > > setbuf(3): Remove bugs section about ancient versions of BSD. > > Modified: > > head/lib/libc/stdio/setbuf.3 > > Modified: head/lib/libc/stdio/setbuf.3 > > ============================================================================== > > --- head/lib/libc/stdio/setbuf.3 Fri Feb 15 09:10:01 2013 (r246823) > > +++ head/lib/libc/stdio/setbuf.3 Fri Feb 15 10:44:07 2013 (r246824) > > ... > > @@ -195,19 +195,3 @@ and > > functions > > conform to > > .St -isoC . > > -.Sh BUGS > > -The > > -.Fn setbuffer > > -and > > -.Fn setlinebuf > > -functions are not portable to versions of > > -.Bx > > -before > > -.Bx 4.2 . > > -On > > -.Bx 4.2 > > -and > > -.Bx 4.3 > > -systems, > > -.Fn setbuf > > -always uses a suboptimal buffer size and should be avoided. > This also removes the bugs section about setbuf() being unusable. It > uses a buffer of size BUFSIZ, but that is unusably small. This bug > is older than the old versions of BSD (setbuf() was broken as designed) > but still applies. So I should put back a BUGS section with the below? ] .Fn setbuf ] always uses a suboptimal buffer size and should be avoided. The risk is not very high because the lazy thing to do (not calling setbuf() at all) gives better results than calling setbuf(). > BTW, I recently noticed many utilities using too-small stdio buffers: > - md5(1) and libmd use raw BUFSIZ to get the same slowness as setbuf(). > They even try to get misaligned buffers by allocating them as char > arrays on they stack. md5(1) calls fread() for BUFSIZ bytes at a time. This causes more memory copies than necessary but does not affect the stdio buffer size passed to read(2). > - cmp(1) in the non-regular file case naively believe that stdio chooses > a good buffer size, and stdio naively believes that stat()'s > st_blksize is a good buffer size. The latter is still broken in the > kernel (it was unbroken a couple of years ago for regular files). Any way to fix stdio? > So cmp [-lx] on disks runs very slowly. cmp's internal algorithms > are also very slow (starting with using stdio at all), but can keep > up with disks provided the disks are slowed down like this. The > non-regular file case is little better. It uses mmap() and a > different slow internal algorithm (not quite as slow since it doesn't > use stdio). mmap() is especially suitable for disk files, but cmp > "knows" that it only works on regular files. cp(1) and install(1) use > mmap() more reasonably. mmap() is generally worse than read()/write() if you only access the data once. VM manipulations are not free. In the interest of simplicity it may be good to remove the extra code and only use read()/write(). -- Jilles Tjoelker