From owner-cvs-all@FreeBSD.ORG Wed Mar 24 19:41:06 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8C9A216A4CF; Wed, 24 Mar 2004 19:41:06 -0800 (PST) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i2P3f25I089909; Wed, 24 Mar 2004 22:41:02 -0500 (EST) (envelope-from green@green.homeunix.org) Received: from localhost (green@localhost)i2P3f27p089906; Wed, 24 Mar 2004 22:41:02 -0500 (EST) (envelope-from green@green.homeunix.org) Message-Id: <200403250341.i2P3f27p089906@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Mike Silbersack In-Reply-To: Message from Mike Silbersack <20040324195119.R39855@odysseus.silby.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Mar 2004 22:41:01 -0500 Sender: green@green.homeunix.org cc: Brian Feldman cc: David Schultz cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen arc4random.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2004 03:41:07 -0000 Mike Silbersack wrote: > > On Wed, 24 Mar 2004, David Schultz wrote: > > > > Add locking so that arc4random(3) functions are all reentrant for > > > pthreads. > > > > I think you mean thread-safe, not reentrant. Also: > > PR: 63287 > > > > AFAIK, there's no standard for how arc4random() is supposed to > > behave, but the new behavior is a break from that of other BSDs, > > and from the behavior of random(), so the change should probably > > be documented in the manpage. > > Er, what would the manpage say? "arc4random no longer corrupts its state > when called simultaneously?" If our other library routines do not > guarantee this, they probably should be changed so that they do. There's no reason to make a distinction. Quoth the OED: "b. Computers. Of, pertaining to, or designating a program or subprogram which may be called or entered many times concurrently from one or several programs without alteration of the results obtained from any one execution." > > FWIW, on my UP Pentium 4 with SMT, this adds roughly 3% overhead > > for unthreaded apps and 52% overhead for threaded apps. It is > > conceivable that an application writer would want access to the > > raw interface in order to serialize calls manually for efficiency, > > but I'm not such an application writer, so I won't complain. > > As I said when I locked down arc4random in the kernel, it would be > possible to use seperate entropy buckets for each processor (or thread) if > performance really becomes an issue. Agreed. We should be providing reentrant interfaces except where explicitly unable to do so, run-time cost not being the primary concern. That said, the man pages for all non-reentrant interfaces should be annotated as such. The submitter has hinted that he may compile a full list of all of those :-) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\