Friedrich Dominicus wrote:
According to threads(3) and also mentioned in "network security with
OpenSSL" from O'Reilly one has to provide callback functions for using
OpenSSL with threads.
The callbacks abstract the thread locking/mutex requirements inside
OpenSSL library to manipulate its global variables.
Now there do exist a few libraries (e.g libapr and glib) and they have
libraries for thread support also, and now comes my question. What is
the id_function while using glib?
Ideally pthread_self().
You did not say what platform you were working with.
This is what I do on linux:
static unsigned long
linux_id_function(void)
{
/* This needs to be unique per thread */
return pthread_self();
}
void
openssl_init(void)
{
unsigned long (*id_function)(void);
id_function = linux_id_function;
CRYPTO_set_id_callback(id_function);
}
can I simply cast one member of the GThread struct? (maybe data?)
Thats possible but my next best suggestion is to use the start offset of
the stack if you can work it out. All versions of linux and windows
have function calls that can uniquely identify a thread. Are you one a
different platform ?
If you use GThread offset this presumes that you will only every call
OpenSSL from a thread created via a GThread context. In any case how do
you get the GThread offset for the current thread anyway, I thought
GThread was a control structure that represents a thread. Which means
if you are that thread then the only way of getting it back without
passing it around is by using Thread Local Storage. But if you have a
platform with working TLS then you probably already have a way of
getting a unique thread identifier via an API call.
alternatively what would be the callback function for libapr?
??? Lost me there...
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
