Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Aug 1999 22:45:36 +0000
From:      Francis Jordan <frankrj@netscape.net>
To:        shocking@prth.pgs.com
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Threaded X libraries
Message-ID:  <37B4A010.58E32CC6@netscape.net>

next in thread | raw e-mail | index | archive | help
> I'm attempting to build the X11 libs with the thread safety stuff (I beleive
> Linux can already be built like this) and have discovered when linking that
> we don't have the getpwnam_r & getpwuid_r functions in out libc_r. Is anyone
> planning on adding these?


I asked the same question a while ago, and Wes Peters replied saying
that the getpwent_r routines would probably require the newlib version
of dbm, to ensure proper locking of the database.

It also seems that apart from getpwnam_r() and getpwuid_r(), X requires
a whole bunch of other reentrant functions, namely:

readdir_r(): <dirent.h>
getgrgid_r(), getgrnam_r(): <grp.h>
gethostbyname_r(), gethostbyaddr_r(), getservbyname_r(): <netdb.h>
strtok_r(): <string.h>
asctime_r(), ctime_r(), localtime_r(), gmtime_r(): <time.h>
getlogin_r(), ttyname_r(): <unistd.h>

(see xc/include/Xos_r.h)

Of these, FreeBSD libc_r only has the *time_r() functions and
strtok_r().  Recently there was a discussion about implementing
reentrant versions of the resolver functions (get*by*_r()), and someone
mentioned that the latest release of BIND already has them thread-safe.

It's probably not very hard to implement the remaining functions by
replacing the static variables by caller-supplied buffers, and locking
access to provide safety from different threads calling the same
function at the same time, but unfortunately it still means serialized
access.  It would be nice to have a _true_ multithreaded implementation,
but this is problematic until we lose the big giant lock and evolve some
sort of kernel threads or LWPs.

Frank

P.S. A question for Warner Losh -- what happened to the idea of bringing
NetBSD's kernel threads implementation into the kernel?


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37B4A010.58E32CC6>