> > > 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. > > "David Schwartz" <dav...@webmaster.com> wrote: > > > > 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.) > Sad Clouds wrote: > > It's a bad way of doing network programming.
No, it's a perfectly good, sensible, straightforward and simple way to do 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. Indeed. That makes two-threads-per-connection inappropriate for use with thousands of connections on most systems. Many network programs have a maximum of one or two connections, or another small number; for such programs having separate read and write threads can be a simple elegant solution. > The usual way to handle concurrent connections is to set sockets > non-blocking and use event notification - poll, epoll, kqueue, ports, > etc. That's the usual way to handle significant numbers of connections. For many programs handling a small number of connections, two threads per connection is the normal approach. It's simpler, and much easier to port between OSes. Horses for courses. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
