From owner-freebsd-hackers Wed Feb 17 15:48: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 1631210FEF for ; Wed, 17 Feb 1999 15:48:01 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id PAA10150; Wed, 17 Feb 1999 15:47:28 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA24271; Wed, 17 Feb 1999 15:47:27 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id QAA06998; Wed, 17 Feb 1999 16:47:25 -0700 Message-ID: <36CB550D.7C1065F3@softweyr.com> Date: Wed, 17 Feb 1999 16:47:25 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: dave@jetcafe.org, freebsd-hackers@FreeBSD.ORG Subject: Re: getpwnam and getpwnam_r References: <199902171850.LAA21086@usr07.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > Where are the thread-safe, reentrant versions of this routine in > > > FreeBSD 3.1? > > No additions to the list (I'm too tight for time to look at my CDROM > at the moment). > > The routines getpwnam, getspnam are problematic, in general. This is one of the reasons why I was putting them off 'til last. They're an ugly mess, and I'm fighting enough ugly messes at work right now. ;^( > A number of the cron-triggered VM bugs have to do with the dbm > routines mmap'ping the password database (COW), and cron modifying > the contents of the fields, as if they were static buffers in > libc. > > It seems to me that the use of a static structure with pointers > to the relevent "return data" will be problematic for threads > based, reentrant versions of these routines. That's what I'm getting rid of. The _r versions all use a caller-provided buffer to return the data in. The type of buffer provided by the caller is the caller's problem, not mine. If you hand me a buffer I cannot write into, I will gently inform you of this by segv'ing all over your program. > I am loathe to suggest TLS (thread local storage) as a soloution, > since it could easily interfere with marshalling data between > kernel threads (as it does on Windows 95/98/NT) due to it being > outside the common address space as an implementation detail. I actually had not given much thought to the implementation of the really ugly, dbm-based calls like getpw*. I'll burn that bridge when I get to it, I guess. The strtok and time functions were pretty straightforward, since they just run "inside" the caller-supplied buffer. I do, however, realize this is a sticky problem. I originally ventured down this path to support something I was working on, where I have a C++ class that starts a thread in it's constructor and "runs" the object in the thread. The storage used in this case is storage local to the object, allocated via "operator new" (and therefore malloc on G++/FreeBSD, right?). I haven't bothered to trace the performance ramifications of this storage model yet because the program is less than half implemented. -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message