Date: Wed, 24 Mar 2004 19:55:05 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: David Schultz <das@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen arc4random.c Message-ID: <20040324195119.R39855@odysseus.silby.com> In-Reply-To: <20040325013941.GA65920@VARK.homeunix.com> References: <200403241444.i2OEiv86083617@repoman.freebsd.org> <20040325013941.GA65920@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040324195119.R39855>