httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Schumann <sas...@schumann.cx>
Subject Re: [?PATCH?] using getpwnam_r in mod_userdir
Date Fri, 10 Nov 2000 22:04:29 GMT
On Fri, 10 Nov 2000 rbb@covalent.net wrote:

> > >
> > > Argh.  :-(  The general rule that we used in APR was that if
> > > _POSIX_THREAD_SAFE_FUNCTIONS is defined, then we can use the _r
> > > functions.  The problem is that with the patch below, the code is broken
> > > when using threaded httpd on FreeBSD.  How does 3.4 provide a thread-safe
> > > version of getpwnam?
> >
> >     This is FreeBSD land where POSIX does not matter. =)
> >
> >     Wes Peters wrote 1.5 years ago[1] that he might implement
> >     getpwnam_r and related functions, but I don't see them in
> >     the -current tree.
>
> Well that's bogus.  Does that mean that FreeBSD doesn't do threadsafe
> getpwnam?  I have no good answer for this.  I guess we check if getpwnam_r
> is available, but this is just wrong.

    Well, it is a standard problem of writing portable reentrant
    code.

    Our "user" code like mod_userdir.c should just assume that
    getpwnam_r exists. If it does not exist, we can provide a
    fallback which serializes access to the OS-function.
    Otherwise, we start duplicating work-arounds and checks all
    over the place.

    I'm attaching such a fallback for getpwnam_r. There are two
    issues with this:

    -   ACQUIRE_LOCK/RELEASE_LOCK should be defined to mutex-like
        functions, if we are compiling thread-safe (otherwise,
        they are nops).
    -   The getpwnam_r function should be prefixed properly to
        avoid conflicts with system functions which have the same
        name, but another interface.

    The locks probably require a small framework for
    initialization like we do here:

    http://lxr.php.net/source/php4/main/reentrancy.c

    Comments?

    - Sascha

Mime
View raw message