you should be setting the non blocking thing before the ssl connect is called, which is part of the SSL handshake. SSL_connect will internally do socket read/write, so if its blocking then it will not come out until the underlying operation is completed. setting it after the SSL connect is done, will help only on application data read/write.
Thanks --Gayathri On Mon, Jan 16, 2012 at 10:47 AM, Nathan Smyth <naf...@ymail.com> wrote: > Yes, strangely this doesn't help. Actually, what I do is set the socket to > non-blocking AFTER the SSL handshake, which I thought should work... > > Could there be some issue with numerous SSL connections between the same > parties? Or maybe it's some threading issue - perhaps SSL has some special > considerations? > > ------------------------------ > *From:* Gayathri Sundar <suraj...@gmail.com> > *To:* openssl-users@openssl.org > *Sent:* Monday, 16 January 2012, 16:21 > *Subject:* Re: Deadlock - SSL_Connect() > > did you try making use of non blocking fd? it cannot deadlock in if you > use that. > > Thanks > --Gayathri > > On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth <naf...@ymail.com> wrote: > > Just seeking advice/things to consider for deadlock (or 'wait') on a > SSL_Connect(). Unfortunately it stalls here, so there's no return code. > > The project establishes a number of SSL conns between various application > instances. It's in C++, where standard socket libs are used to establish > the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). > Normal sockets (i.e. without SSL) are used for local inter-proc comms - > maybe this is relevant? > > I've been stuck for a while - and advice as to common > areas/mistakes/considerations are most appreciated. > > Thanks! > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > > > >
