From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christopher Wellons Newsgroups: gmane.emacs.bugs Subject: bug#20159: 24.4; url-retrieve invokes same callback twice with kill-buffer Date: Sat, 21 Mar 2015 17:48:05 -0400 Message-ID: <87egoi3tuy.fsf@wellocc1-ld2.jhuapl.edu> References: <87k2ya3wpz.fsf@wellocc1-ld2.jhuapl.edu> <83y4mqrrp8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426974565 7930 80.91.229.3 (21 Mar 2015 21:49:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 21:49:25 +0000 (UTC) Cc: 20159@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 21 22:49:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YZRGb-0005Hi-G6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 22:49:13 +0100 Original-Received: from localhost ([::1]:49076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZRGa-0004qi-Iz for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 17:49:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40367) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZRGW-0004qd-CT for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:49:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZRGR-0007Xn-C8 for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:49:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZRGR-0007Xj-8Q for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:49:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZRGQ-0001Lh-Jg for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 17:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Christopher Wellons Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Mar 2015 21:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20159-submit@debbugs.gnu.org id=B20159.14269744915128 (code B ref 20159); Sat, 21 Mar 2015 21:49:02 +0000 Original-Received: (at 20159) by debbugs.gnu.org; 21 Mar 2015 21:48:11 +0000 Original-Received: from localhost ([127.0.0.1]:60117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZRFb-0001Kd-BF for submit@debbugs.gnu.org; Sat, 21 Mar 2015 17:48:11 -0400 Original-Received: from mail.nullprogram.com ([192.241.191.137]:55562) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZRFZ-0001KV-O7 for 20159@debbugs.gnu.org; Sat, 21 Mar 2015 17:48:10 -0400 Original-Received: from localhost ([127.0.0.1] helo=wellocc1-ld2.jhuapl.edu) by mail.nullprogram.com with esmtp (Exim 4.84) (envelope-from ) id 1YZRFX-0000Rg-PA; Sat, 21 Mar 2015 17:48:08 -0400 In-Reply-To: <83y4mqrrp8.fsf@gnu.org> User-Agent: Notmuch/0.18+10~g7d81d70 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-unknown-linux-gnu) X-Hashcash: 1:20:150321:eliz@gnu.org::O2lRXjehEdBr+uek:000009NEW X-Hashcash: 1:20:150321:20159@debbugs.gnu.org::v1xsmbDw3XcJpEvW:000000000000000000000000000000000000000099rp X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100765 Archived-At: >> 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!