Date: Wed, 24 Mar 2004 22:23:14 -0800 From: David Schultz <das@FreeBSD.ORG> To: "Brian F. Feldman" <green@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen arc4random.c Message-ID: <20040325062314.GA66442@VARK.homeunix.com> In-Reply-To: <200403250341.i2P3f27p089906@green.homeunix.org> References: <20040324195119.R39855@odysseus.silby.com> <200403250341.i2P3f27p089906@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040325062314.GA66442>