Kyle, Thanks for your long and detailed response.
> OpenSSL can protect its internal state by employing locks on the > things that are interface-opaque. It cannot protect its transparent > state, especially as things other than OpenSSL that "just happen to > know how the interface works" may not use the same locking services. > This is why the requirement is pushed to the user to do thread-safety > in these situations. > > SSL_read() can update the write state. SSL_write() can update the > read state. All of the SSL_*() functions are thread-unprotected > within the library -- but, as long as you ensure that there's no > concurrent access to the SSL object, you can make use of it in > multiple threads. You just have to make sure it's never used in > multiple threads *simultaneously*, because if that occurs the SSL > layer WILL throw a fatal alert (decryption failure, bad_hmac, or bad > sequence). > > So, the condensed version is: If you don't use SSL objects in more > than one thread, you don't need to lock them -- so why should OpenSSL > take the time and waste the resources to lock them (and risk resource > exhaustion for the entire application)? If you do use SSL objects in > more than one thread, you do need to lock them. That is the same type > of requirement pushed onto EVERY multithreaded application that needs > to directly access the same data from multiple threads -- which > implies that you know that you need the locks, and thus must provide > them. (If there's a helper function that does the reading or writing > itself, you can just do the lock and unlock there.) > > I hope this helps. Yes. Thanks. Regards, Mark ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
