> > 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
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
|