From owner-freebsd-hackers Fri Aug 13 14:44:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from amstech.com (alister.w.easynet.co.uk [212.212.251.86]) by hub.freebsd.org (Postfix) with ESMTP id DE29514F22 for ; Fri, 13 Aug 1999 14:44:07 -0700 (PDT) (envelope-from frankrj@netscape.net) Received: from netscape.net (localhost [127.0.0.1]) by amstech.com (8.9.3/8.9.1) with ESMTP id WAA00596; Fri, 13 Aug 1999 22:45:47 GMT (envelope-from frankrj@netscape.net) Message-ID: <37B4A010.58E32CC6@netscape.net> Date: Fri, 13 Aug 1999 22:45:36 +0000 From: Francis Jordan X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: shocking@prth.pgs.com Cc: freebsd-hackers@freebsd.org Subject: Re: Threaded X libraries Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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(): getgrgid_r(), getgrnam_r(): gethostbyname_r(), gethostbyaddr_r(), getservbyname_r(): strtok_r(): asctime_r(), ctime_r(), localtime_r(), gmtime_r(): getlogin_r(), ttyname_r(): (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