"4b0e01f Retry SSL_connect when SSL_get_error requests it. " from David Galeano
noticed the problem that client connect may receive SSL_ERROR_WANT_* from
SSL_connect, which is basically WOULDBLOCK. That patch tried to deal with it
by blocking in a while(1) until the condition went away.
That's problematic because of it blocks service of anything else (including
the host application sockets in the external socket poll sharing case) for
up to 5s controlled by conditions at one client.
After fiddling with and researching this, the actual problem with the code is
we are not getting the SSL layer error correctly, it is not contained in the
code returned from the Connect api directly.
I was unable to get a renegotiation forced on my modern SSL libs, it complained
about protocol error are reopened the connection instead. So I think the stuff
found in the docs and the web about the SSL_ERROR_WANT_ is probably not something
we will see in reality (if we check the right error code...)
Signed-off-by: Andy Green <andy.green@linaro.org>
73abc25cb5