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]
