Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Mar 2004 22:41:01 -0500
From:      "Brian F. Feldman" <green@FreeBSD.ORG>
To:        Mike Silbersack <silby@silby.com>
Cc:        cvs-src@FreeBSD.ORG
Subject:   Re: cvs commit: src/lib/libc/gen arc4random.c 
Message-ID:  <200403250341.i2P3f27p089906@green.homeunix.org>
In-Reply-To: Message from Mike Silbersack <silby@silby.com>  <20040324195119.R39855@odysseus.silby.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack <silby@silby.com> 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.                       \,,,,,,,,,,,,,,,,,,,,,,\




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403250341.i2P3f27p089906>