Hi We are using the multiple contexts (although not same as thread count i.e. 10 Contexts for 3 threads).. Select call may be failing as the default FD_SET_SIZE is 255 on most systems and thus in case u want to handle 1000 sockets u need to increase the limit.. There is #def in some Windows file.. chk that.. (Assuming u are running this on Windows)...
Running 1000 Contexts.. wow.. that would must be challenging and there might be some assumptions about max. Contexts per application...Best thing would be to start with N=10 Context and than may be check the limit where it fails.. Than search for that limit in the openSSL code. That might give us the location where it is hardcoded.. HTH Regards -Krishna Flextronics, Gurgaon, India On 6/26/06, Ambarish Mitra <[EMAIL PROTECTED]> wrote:
Some days back, we had a riot on "select" call usage. You may revisit those posts to see if it is helpful. One thing I do not get is: "Each thread has it's own SSL context ". I also had a mult-threaded application, and for the entire process, there was only one context created with SSL_CTX_new. The individual threads had their own SSL objects from the context using SSL_new. SSL_new takes the SSL context as the input argument. Therefore, I think creating as many SSL contexts as many threads are there is an issue. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Leon Sent: Monday, June 26, 2006 12:19 PM To: openssl-users@openssl.org Subject: OpenSSL and multiple threads Hi, I wrote a server app to use multiple threads. Each thread has it's own SSL context and perform all the socket (socket,accept) and SSL (SSL_accept) tasks. I implemented the dynamic lock mechanism for multi thread support. I can start the server with the 1000 threads (one for each required port) that we need, but found that it fails if I try 1500. Now I am afraid that the 1000 threads may also become unstable with continuous use. This failure occurs when all the threads are listening and I open a single connection to one of them. That is: there is no load. I tracked the bug with gdb and found that it fails in RAND_poll(), called from SSL_accept(), when a new session key is generated. The strange thing is that after the file descriptor set is zeroed [(FD_ZERO(&fset)] the call [FDSET(fd,&fset)] to add the random device's file descriptor does not work. The set remains zeroed and once the select() has executed using this set, most of the parameters including the random devices file descriptor, becomes zeroed (NULL). It looks as if something is overrunning my stack - any ideas as to how to get the sucker? I had the same results on a dual xeon as well as a Athlon box. Using 0.9.7e. Please ignore the design - it is suppose to be experimental. Thanks Leon ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
