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

[David Schultz]

On Wed, Mar 24, 2004, Brian F. Feldman 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:
[...]
> 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."

Some people use ``reentrant'' to convey a stronger notion than
``thread safe''.  Specifically, reentrancy implies that multiple
invocations of the function can execute correctly in parallel,
rather than having a big lock around the whole thing.  But in this
case, you're right that there's no need to make a distinction, and
it was silly of me to mention it.

> 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 :-)

That would be great!  For all POSIX functions, there's already a
list of non-thread-safe functions at:
http://www.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_09.html
For most of these, e.g. gethostbyname(), it's clear that thread
safety is impossible, so it isn't even necessary to document the
fact.  But for functions such as arc4random(), I think it's a fair
question whether thread-safety is provided or not; that's why I
brought it up.

I also agree with your point that we should prefer thread-safe
interfaces in order to prevent foot-shooting.  On the other hand,
I can also think of specific examples where engineers looked at
the way people used an interface, measured the performance hit for
providing inherent thread safety, and ultimately decided to make
the application programmer responsible for serialization.  For
instance, the Java graphics libraries follow this trend.  I
personally think the designers took the wrong approach in that
case, but my point is that sometimes people *do* care.  If OpenSSL
used libc's RC4 implementation rather than its own, for example,
someone might care about the 50% overhead.  But as I said, I'm not
complaining.  Ignore the man behind the curtain!


P.S. I'm getting on an airplane in a couple of hours, so (perhaps
     to your relief) I won't be able to respond for a few days.