On Mon January 16 2012, Nathan Smyth 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? >
Like in defining the locking call backs maybe? See the OpenSSL docs for details. Mike > > ________________________________ > 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 > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
