While that (not simultaneously accessing the same structure from different threads) is certainly understandable, it is often the case that an SSL implementation will mimic a socket implementation. In fact, the clear socket implementation is always a candidate for SSL work and it is perfectly acceptable to have separate threads reading and writing from/to a socket. The socket itself will handle the contention this may cause. I am getting "beat up" because OpenSSL doesn't follow the "socket model" which seems unreasonable to some of my coworkers trying to use SSL sockets in more or less the same fashion as clear sockets (at least with the same basic architecture).
I know from looking in the email archives that this issue has come up before so we are not the only ones struggling with it. The suggested solution was to create a mutex and use the ex_data for the SSL structure to tie it to the connection and then mutex read/write access. I am willing to do that, but even that is not terribly straight forward. Consider: We have one thread wanting to write a large amount of data (say 2 Meg). OpenSSL will break that data up into 16k chunks, SSLize them and write each separately. During the process, it is using the "rwstate" in the SSL structure to indicate the status of the write operation. How do I then process a "cancel" instruction that I might receive from an impatient client who decides they don't want or need to see all 2 Meg of data? Is it safe to do a read operation between the writes of each 16k chunk or do I need to wait until all 2 Meg have been written? With clear sockets, a separate thread for reading and writing works very well to handle this. With OpenSSL, the state of the write can easily be stomped on by reading the "cancel". Verdon >>> [EMAIL PROTECTED] 3/18/2003 7:10:23 PM >>> On Mon, 17 Mar 2003 11:26:46 -0700, Verdon Walker wrote: >I know from looking in the archives that this question has been >asked >before, but I am wondering if anything has been done in the 0.9.7 >branch >to address it. >We have an application that uses separate threads for its readers and >writers. Currently, the threads can stomp on each others state since >they are using the same SSL structure. In particular, the "rwstate" >flag >can get trashed and confuse one thread or the other about what is >happening. I know that OpenSSL does not support this in the 0.9.6 >branch, but was anything done to address it in 0.9.7 or is anything >planned in 0.9.8? No. Most libraries are thread safe in the sense that they work fine so long as two threads don't try to modify the same structure at the same time. Trying to change this generally makes things worse. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]