Hi Sads, On Mon, Apr 19, 2010 at 3:32 AM, Sad Clouds <cryintotheblue...@googlemail.com> wrote: > 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 2.5 and above kernels uses a constant time scheduling algorithm, so the performance hit should be incurred on resource usage and not scheduling. I would expect that the 'penalty for resource usage' would be page faults due to swap file use and contention for the CPU by the threads. See http://www.informit.com/articles/article.aspx?p=101760&seqNum=2.
(If you meant 'running all those threads...', please disregard this comment). > The usual way to handle concurrent connections is to set sockets > non-blocking and use event notification - poll, epoll, kqueue, ports, > etc. > Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
