Date: Thu, 25 Mar 2004 09:13:39 -0500 From: "Brian F. Feldman" <green@FreeBSD.ORG> To: Mike Silbersack <silby@silby.com>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/gen arc4random.c Message-ID: <200403251413.i2PEDdxq093521@green.homeunix.org> In-Reply-To: Message from David Schultz <das@FreeBSD.ORG> <20040325062314.GA66442@VARK.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz <das@FreeBSD.ORG> wrote: > 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. Yeah, whether the code is actually entirely thread-independent or utilizes mutual exclusion to achieve that effect is probably something we should also document. > > 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. Well, according to POSIX, random(3) is supposed to be thread-safe in the same manner -- shared data between all threads. Unfortunately, since ours does not provide that ability transparently, it's certainly not pthreads- compliant. Since arc4random(3) is meant as mostly a much stronger replacement for random(3), it seems right to give it the same semantics. Here's a cursory list of "most of" the files in libc that are unsafe. I didn't even try to look for static non-globals and non-static globals, so there's undoubtedly some of every category missing. posix1e/mac.c gen/fstab.c gen/getcap.c gen/getgrent.c gen/getnetgrent.c gen/getpwent.c gen/getpwent.c gen/getttyent.c gen/getusershell.c gen/getvfsent.c gen/syslog.c gen/readpassphrase.c locale/setlocale.c locale/lmessages.c locale/lmonetary.c locale/lnumeric.c net/gethostbydns.c net/gethostbyht.c net/gethostbynis.c net/getnetbydns.c net/getnetbyht.c net/getprotoent.c net/getservent.c net/hesiod.c net/gethostnamadr.c net/nsparser.y rpc/auth_time.c rpc/clnt_perror.c rpc/clnt_simple.c rpc/getnetconfig.c rpc/getrpcent.c rpc/key_call.c rpc/rpcdname.c rpc/svc_auth_des.c rpc/svc_auth.c rpc/clnt_dg.c rpc/rpcb_clnt.c stdlib/rand.c stdlib/random.c stdlib/hcreate.c stdlib/getopt_long.c stdtime/timelocal.c yp/yplib.c This is more difficult because of the sheer abundance of non-const constants in use, but is probably mostly accurate. -- 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?200403251413.i2PEDdxq093521>