On Tue, Jun 01, 1999 at 09:03:31PM +0000, Patrick Bertholon wrote:
> To handle multiple connection simultaneously, I have one "network"
> thread, that start the SSL connection when a client connects. After
> that, it gives the connection (the SSL*) to another thread and waits for
> another client. I think that SSL can't handle this, even with these
> callback functions, as it might be using ThreadID to distinguish between
> connections when they are lots.
No, the thread lD is used only by the error library. The threads
won't be able to read each other's error messages, but apart from
that, the library doesn't care which threads does what. If the
processes sufficiently synchronize (i.e. never two of them try to use
the same SSL * at the same time or things like that), there should be
no problem. Those things that need to be threadsafe are (I should
hope), e.g. lots of threads can call SSL_new for the same SSL_CTX *.
(It looks more natural to have the SSL_CTX * in a global context and
create the derived SSL *'s in the individual threads, but of course
you can also pass SSL *'s to the sub-processes.)
Just never forget to call ERR_remove_state(0) before a thread quits,
or to call ERR_remove_state(id) from the main thread if the main
thread always can detect which childs finished.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
