> Is it the case that both SSL_read and SSL_write modify the same > part of the > SSL object ?
Yes, but that's not the issue. > Could you give some more details about this? Could you throw some > more light > on the ssl state maintained > by the SSL object during SSL_read and SSL_write? I'm not sure why more internal details of how OpenSSL works would be helpful. I've already explained the external interface. > Is it safe if I programmatically make sure (say using mutex) that only one > thread is accessing the SSL object at any time? Yes. > In that case, would it be okay to call SSL_read on one thread and > SSL_write > on other thread? So long as you didn't call them both on the same SSL object at the same time. > Where exactly would the locking callback functions come into picture? The locking callback functions are required to be properly implemented if you are going to use OpenSSL on a multithreaded platform. OpenSSL uses them internally to prevent conflicts. Every sophisticated library that supports multiple threads strikes a balance between thread-safety in the caller and thread-safety in the library itself. This is OpenSSL's balance. It's pretty much the same balance the vast majority of libraries takes. Concurrent calls on the same upper-level object are prohibited. But calls that internally "happen to" access the same lower-level objects are handled by the library. The only reason it's important to mention that you can't access the same SSL object in multiple threads is that TCP allows this. Otherwise, it would be what you would assume. For example, a typical C++ string library is thread-safe, even if it accesses global structures such as a private memory pool, but you can't manipulate the same string at the same time in two threads. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
