(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
