- update OpenSSL to 0.9.8
[dragonfly.git] / secure / lib / libcrypto / man / threads.3
index c0f4089..338f553 100644 (file)
 .\" ========================================================================
 .\"
 .IX Title "threads 3"
-.TH threads 3 "2004-12-18" "0.9.7e" "OpenSSL"
+.TH threads 3 "2005-07-06" "0.9.8" "OpenSSL"
 .SH "NAME"
 CRYPTO_set_locking_callback, CRYPTO_set_id_callback, CRYPTO_num_locks,
 CRYPTO_set_dynlock_create_callback, CRYPTO_set_dynlock_lock_callback,
@@ -211,9 +211,10 @@ different mutex locks. It sets the \fBn\fR\-th lock if \fBmode\fR &
 \&\fBfile\fR and \fBline\fR are the file number of the function setting the
 lock. They can be useful for debugging.
 .PP
-id_function(void) is a function that returns a thread \s-1ID\s0. It is not
+id_function(void) is a function that returns a thread \s-1ID\s0, for example
+\&\fIpthread_self()\fR if it returns an integer (see \s-1NOTES\s0 below).  It isn't
 needed on Windows nor on platforms where \fIgetpid()\fR returns a different
-\&\s-1ID\s0 for each thread (most notably Linux).
+\&\s-1ID\s0 for each thread (see \s-1NOTES\s0 below).
 .PP
 Additionally, OpenSSL supports dynamic locks, and sometimes, some parts
 of OpenSSL need it for better performance.  To enable this, the following
@@ -265,14 +266,14 @@ should not be used together):
 \&\fICRYPTO_get_new_dynlockid()\fR returns the index to the newly created lock.
 .PP
 The other functions return no values.
-.SH "NOTE"
-.IX Header "NOTE"
+.SH "NOTES"
+.IX Header "NOTES"
 You can find out if OpenSSL was configured with thread support:
 .PP
 .Vb 7
 \& #define OPENSSL_THREAD_DEFINES
 \& #include <openssl/opensslconf.h>
-\& #if defined(THREADS)
+\& #if defined(OPENSSL_THREADS)
 \&   // thread support enabled
 \& #else
 \&   // no thread support
@@ -281,6 +282,22 @@ You can find out if OpenSSL was configured with thread support:
 .PP
 Also, dynamic locks are currently not used internally by OpenSSL, but
 may do so in the future.
+.PP
+Defining id_function(void) has it's own issues.  Generally speaking,
+\&\fIpthread_self()\fR should be used, even on platforms where \fIgetpid()\fR gives
+different answers in each thread, since that may depend on the machine
+the program is run on, not the machine where the program is being
+compiled.  For instance, Red Hat 8 Linux and earlier used
+LinuxThreads, whose \fIgetpid()\fR returns a different value for each
+thread.  Red Hat 9 Linux and later use \s-1NPTL\s0, which is
+Posix\-conformant, and has a \fIgetpid()\fR that returns the same value for
+all threads in a process.  A program compiled on Red Hat 8 and run on
+Red Hat 9 will therefore see \fIgetpid()\fR returning the same value for
+all threads.
+.PP
+There is still the issue of platforms where \fIpthread_self()\fR returns
+something other than an integer.  This is a bit unusual, and this
+manual has no cookbook solution for that case.
 .SH "EXAMPLES"
 .IX Header "EXAMPLES"
 \&\fBcrypto/threads/mttest.c\fR shows examples of the callback functions on