>> But the point I tried to address is the following: /When/ shall we start
>> with the handshake "series" and start counting the number of tries (or
>> stopwatch)?  Don't you agree that with async sockets, it doesn't make
>> much sense to start it before the socket is connected?  So we could just
>> postpone it until then...  Otherwise, the number of handshake tries (or
>> time elapsed) durnig the "socket not yet connected" are subtracted from
>> the max number of tries (or timeout) granted.  Which I think is, well,
>> at least imprecise...
>
> I think we are looking in the wrong direction.  We need first to
> understand why the connection(s) to download the images don't work.
> Does anyone already have an idea why this happens?  If so, please
> describe that.

I must admit that I have holes in my mental model, and I'm still
observing flows at runtime which seem strange to me.  So yes, it may be
the wrong direction regarding the /issue/.  But I was not only referring
to the issue, but also to an optimization of the new async paths...

> There is also some disturbing signs in retrying GnuTLS handshake from
> wait_reading_process_output -- I'm not sure the way that function
> works, at least on Windows, is according to you expectations.  The
> while loop there doesn't really spin all the time, did you know that?
> Can you describe what you think should happen there for a connection
> whose GnuTLS handshake is not yet complete?

Hmm.  What I observed is that it stops if the Emacs window looses its
focus (and no other window messages are dispatched to the window).  If
it has focus, it gets called at least once per second.