On Sun, 18 Apr 2010 21:11:40 -0700 "David Schwartz" <dav...@webmaster.com> wrote:
> > Sad Clouds wrote: > > > > 1) According to the FAQ, "an SSL connection may not concurrently > > > be used by multiple threads". Does this mean that an SSL > > > connection can be used by different threads provided access is > > > limited to one at a time? > > > > I assume that having a mutex for each SSL object would prevent it > > from being concurrently used by multiple threads. So this should be > > OK. > > Yes, that works. However, you can't use blocking operations in that > case. Otherwise, a thread trying to write to the connection would be > blocked potentially for ever as some other thread blocked trying to > read from the connection held the connection lock. > That's not the way to do it on Unix. > > However do you really need to use multiple concurrent threads with > > the same SSL object? Think of it as a TCP socket, each thread has a > > list of open sockets, or SSL objects, there is no need to share it > > with other threads. > > Actually, it's pretty common to do that with TCP connections. You may > have one thread that's blocked trying to read from the connection all > the time while another thread tries write to the connection as it > discovers data that needs to be sent. You can't do this with OpenSSL. > (At least, not precisely the same way.) It's a bad way of doing network programming. A server can potentialy have 1000s of open sockets, if you have two threads for each sockets, (one for reading, one for writing), pretty soon you'll run out of memory. Scheduling all those threads will have a negative impact on performance. The usual way to handle concurrent connections is to set sockets non-blocking and use event notification - poll, epoll, kqueue, ports, etc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
