bug#20159: 24.4; url-retrieve invokes same callback twice with kill-buffer

[Christopher Wellons <wellons@nullprogram.com>]

>> I also tested this on a Windows build of Emacs. The callback is invoked
>> zero times because the connection error is delivered synchronously at
>> the call to `url-retrieve' (which I now realize explains why connection
>> queuing doesn't work right on Windows). So even if the double-invoke
>> problem is fixed for Linux, the behavior still differs across platforms.
>
> I don't understand what you mean by "error is delivered synchronously
> at the call", and by "connection queuing doesn't work right".  Please
> consider elaborating on those 2 points.

On Windows, url-retrieve doesn't return until the connection is either
established or fails, making the call mostly synchronous. If the remote
server takes 20 seconds to SYNACK, Emacs will lock up for 20 seconds
(and C-g doesn't work either!). For example, currently the server at
example.com doesn't seem to respond to anything, so try evaluating the
following on Windows. For me, Emacs freezes for 21 seconds, until timing
out, and the callback is never invoked.

    (url-retrieve "http://example.com:1/" (lambda (_)))

On Linux it returns immediately and about a minute later the callback is
invoked with an error status, timing out. I could call this 100 times in
a loop without locking up Emacs. On Windows 7 on my computer, this locks
up Emacs for half an hour, though hitting C-g will stop it within 21
seconds (between loop iterations):

    ;; Try it if you dare!
    (dotimes (_ 100)
      (ignore-errors
        (url-retrieve "http://example.com:1/" (lambda (_)))))

Since it's synchronous on Windows, the error can be reported directly to
the caller, which is what it does. The downside is awful performance and
inconsistent error reporting (sometimes synchronously to the caller,
sometimes asynchronously using the callback).

I maintain the Elfeed RSS/Atom reader. I've noticed over the past 1.5
years that its performance on Windows is very poor compared to Linux.
It's bad enough that I've disabled parallel fetching of feeds on
Windows. I see now that it's probably because url-retrieve isn't fully
synchronous there. If I call url-retrieve four times in a row to fire
off four connections, the TCP connections themselves will be performed
serially between calls and not in parallel, as it is on Linux, so
there's no point to doing so. They don't queue properly.

I hope that explains it well enough!