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 >
