Carson Gaspar wrote:
> <sigh> Locking these is going to be a significant performance hit, I
> suspect. Does anyone care about systems that can't handle dinky memory
> allocations for a hostent structure? If so, they should have special case
> code that does locking, #ifdef'd out to protect the rest of us who couldn't
> care less.
>
> As for non-POSIX semantics, I _believe_ that Solaris 7 and HPUX 11.x use the
> POSIX versions of xxx_r. For older, non-compliant versions, they can use the
> locking code (or someone can contribute Yet Another OS Hack).
>
> I _really_ don't want the limitations of broken OS's to cripple the
> performance of good OS's.
Using locks is nice in the code because one implementation works for all platforms,
whether or not threads are enabled. Otherwise there would have to be at least
four #ifdef'ed ways of doing gethostbyname(), for example. These locks shouldn't
be a noticable performance hit anyway. The functions involved aren't called
very often and they execute quickly except for maybe gethostbyname(), and its
impact is mitigated by a local cache in BIO_gethostbyname().
Maybe there should be a POSIX_THREADS define that means the system supports the
final POSIX threads standard, that's used to #ifdef code that uses the _r functions
instead of locks. In fact, there might even be a POSIX standard define that
could be recruited (does _POSIX_C_SOURCE imply POSIX threads compliance?).
There's no one actively developing or testing for POSIX compliance at the moment.
Maybe it can be combined with the X/Open effort that was mentioned the other day.
Volunteers take one step forward.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
