Below remark do *not* mean that issue is dismissed, only that using
Sleep(1) probably is not really good programming practice. The
"work-around" mentioned closer to the end of originating report should
not be considered as "work-around", but as *proper solution*.
> Problem: While using non-blocking I/O, a *second* call to
> BIO_do_connect() always returns non-zero even if the underlying
> connection has not yet been established. A subsequent SSL_connect()
> fails with SSL_ERROR_SYSCALL. (A subsequent WSAGetLastError() returns
> 10057 == WSAENOTCONN == Socket is not connected.) Using
> BIO_should_retry() does not circumvent the problem; it is equally
> misleading as BIO_do_connect().
>
> Here's a rough outline of code to trigger the bug.
>
> BIO *_bio = BIO_new(BIO_s_connect());
> BIO_set_nbio(_bio, 1);
> BIO_set_conn_hostname(_bio, "foo.bar.baz:123"); // some hostname:port
>
> while(1) {
> int r = BIO_do_connect(_bio);
>
> ...
>
> Sleep(1); // ie, sleep for one *millisecond*
> }
What do we know about Sleep? MSDN says that "If dwMilliseconds is less
than the resolution of the system clock, the thread may sleep for less
than the specified length of time. If dwMilliseconds is greater than one
tick but less than two, the wait can be anywhere between one and two
ticks, and so on." Question what does it mean in case when
dwMilliseconds is *much* less than clock resolution? Does it mean that
it may sleep for approximately clock tick? Or does it mean that it will
use instrumented loop? What is clock resolution? To the last question,
it's variable and it's up to 15ms. Does it mean that Sleep(1) may take
up 15 ms or that it consumes 100% CPU in instrumented loop? Neither
sounds expected... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
