On Sun, Apr 25, 1999 at 02:38:48PM +0200, Ralf S. Engelschall wrote:

>> I think we should by default define _REENTRANT or _THREAD_SAFE or any
>> other system-dependent macros that are needed to get a library that
>> can be used in multi-threaded programs.  (This means, for example,
>> that errno is not a variable, but a macro of the form
>> (*__errno_location()), which uses a thread-local errno location --
>> &errno for the main thread, something different for the other ones).
>> At least when the library is installed to standard locations, it
>> probably can lead to very confusing results if it all depends on
>> whether one used "./config -D_REENTRANT" before compiling and
>> installing the library.

> But doesn't -D_REENTRANT or -D_THREAD_SAFE usually also implicitly
> assumes that one _links_ against the reentrant libc and this way
> doing only half the way could cause problems?

Well, at least for Linux (with glibc 2) and for Solaris I am pretty sure
that the standard libc has no problems with this.  I have no idea,
though, how these things are handled on other systems.

The standard library functions always call __errno_location (glibc) or
___errno (SunOS 5.6) to obtain a pointer to the instance of errno that
they should use.  As long as you don't spawn additional threads, this
function always returns a pointer to the errno global variable, so use
of *___errno() and of errno can be mixed.

Apart from providing additional function prototypes for thread-safe
programs, defining _REENTRANT also changes macro definitions for
things like putc (glibc) or prevents such macros from being defined
(SunOS) -- the *function* in libc is always suitable for both cases,
with -D_REENTRANT and without it.

What about adding a new entry to each Configure definition that
contains the appropriate -D... for systems where this is known to
work and some dummy string for others, so that the user can be warned
that in order to create a library which can be used with threads, they
should look up in their system's documentation any additional compiler 
options that may be needed?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to