> Thanks, Kyle for the reply. > > Does anyone have a definitive answer for this one? It could be a > massive > amount of work for me to rewrite the code if I have to switch to using > a single thread for read/write operations.
Just to clarify, you can use two threads. You can use one for read and one for write if you want. However, just like every other shared object, you cannot let the SSL connection be modified by one thread while another thread is or might be accessing it. You would have this same limitation if instead of an SSL connection you were dealing with a string. You can certainly have one thread write out the string and another thread read it in. You just can't do both of these things at the same time. So, for example, you can wrap all SSL functions in a per-SSL-connection mutex. Note that you can't use blocking sockets if you do this. (Which you really shouldn't anyway, since they have so many disastrous limitations.) As for it being a massive amount of work, just replace every call to SSL_read or SSL_write with a call to check your own queue or put a message on your own queue (you can block on 'read' if the queue is empty and on 'write' if the queue has too much data in it). Then you have some sane code to move data between queues and sockets. You don't mention your platform(s) or your performance requirements, so it's hard to give you precise suggestions. By the way, using a thread for read and a thread for write, per client, is one of the worst possible design patterns. If, for example, you need to read a small message from each of 2,500 clients and respond to them all, about 5,000 context switches will be needed. It's only suitable if you totally don't care about performance. (In which case, just wrap the SSL_read/SSL_write functions.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
