httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [?PATCH?] using getpwnam_r in mod_userdir
Date Sat, 11 Nov 2000 01:00:08 GMT

> > Before anybody tells me we can work around these issues, remember that we
> > really have no idea what functions are called internal to the C Run-time,
> > so we can't fix these problems 100%.  If a platform doesn't provide a
> > known thread-safe implementation, then we really can't hack a valid
> > long-term solution.  Imagine the case where both getpwnam and getpwent
> > make a call to the same function within the C run-time, and we have two
> > modules one that calls getpwent and one that calls getpwnam.  We can't
> > protect ourselves from threading issues in that case.  It isn't possible.
>     That's a problem indeed.
>     Remember that we need to have a wrapper anyway for all of
>     those _r functions, because the source code will use _r
>     functions even in non-threaded mode. (Unless you choose to
>     duplicate code for both modes all over the place.)

You can't do that either.  In many cases, the _r functions are much less
efficient than the non-_r functions.  So, if you always use _r you lose
efficiency.  Our wrappers would actually need to use _r or non-_r based on
how it is compiled.

>     I think we should use a single lock for protecting one
>     sub-system. We need to define `sub-system' here. FreeBSD will
>     need one lock for getpw functions.
>     If a certain platform shows signs of hidden inter-function
>     dependencies, I'd be in favor of disabling threading on that
>     platform. Experience will tell.

My own personal opinion is that this is a bogus problem because some
platforms aren't following the specs.  We shouldn't cater to broken
platforms, especially not open source broken platforms.  Those platforms
should be fixed correctly.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message