cvs commit: src/lib/libc/gen arc4random.c

[Mike Silbersack]

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