(not sure if this is going to work -- I've never replied via gmail to email
received in a digest).

>> "I shouldn't get anything TLS-specific until TCP connection is
established."
> How do you know it isn't established, did you check?

My assumption is that no TLS-related data is sent until TCP handshake is
done (i.e. related ACK received, or whatever it is -- I don't remember
details). But I could be wrong -- I vaguely remember reading about some
optimization where connection was "opening" immediately, but eventually
send or receive was failing because "connection established" packet was
never received. If you claim this is the case in this situation -- I will
happily accept it.

In any way -- I just wanted to report this. "Increase backlog" solution is
working fine for me and github issue submission system warned me to report
bugs here first.

> I suppose there's a very slight chance that error may bubble up for some
related reason such as out of random bits so I guess that's possible.

No. I was thinking maybe libcurl connects asynchronously and initiates
related TLS work speculatively before connection is established and
(depending on how far it went before timeout kicks in) it produces 35
instead of 7.

> Yes. Typically you'd have a multi handle which shares the connection
cache.

Hmm... I need to look into this. Something tells me that having cache of
easy handles (protected by mutex) isn't the most efficient solution either.

> Also please read about libcurl thread safety [4].

Yes, I am aware of all this -- global_init() is called, as well as related
initialization for OpenSSL (array of allocated locks) before we get to MT
code.

Thank you.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-01-14