Date: Wed, 17 Feb 1999 16:47:25 -0700 From: Wes Peters <wes@softweyr.com> To: Terry Lambert <tlambert@primenet.com> Cc: dave@jetcafe.org, freebsd-hackers@FreeBSD.ORG Subject: Re: getpwnam and getpwnam_r Message-ID: <36CB550D.7C1065F3@softweyr.com> References: <199902171850.LAA21086@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36CB550D.7C1065F3>