> Now coming to the first part of your comment. As I understand it, the
> manipulation of SSL connection
> needs mutex, but can the SSL_read(s) and SSL_write(s) be done from two
> threads independently?
It can be done from two threads, but it requires a mutex. Thus the two
threads are not independent, they are coordinated.
> By manipulation do
> you mean only renegotiation and kind or will SSL_read and SSL_write also
> fall under that category?
SSL_read and SSL_write are accesses into the SSL connection state
machine.
You cannot access the same SSL connection from two threads concurrently.
> If it is so then how come I never encountered problems till now for
> reading and writing through the two
> threads (interleaved execution)? The problems came up when I started
> doing renegotiation.
I can't answer the second question, but I can answer the first. Either
you
got lucky, or this is one of those cases where invoking undefined behavior
happens to cause the behavior you expect (in the case of only the
environment you happened to be dealing with).
For example, perhaps your higher level code only writes in response to
data
that has been written, and never receives a second request before a first is
fully replied to. Many protocols work this way (POP, HTTP) and many don't
(IRC, NNTP with streaming). For protocol in the first case, it will 'just
happen' that you will only read in cases where you don't have a full reply
that you haven't already replied to and only write in cases where you do
have a full reply that you haven't already replied to. So those protocol may
never be able to cause a crash despite your bug.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
