From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: url.el blocks Gnus+nnrss Date: Tue, 25 Jan 2005 11:51:05 -0500 Message-ID: References: <87pt09v2m1.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1106674011 17676 80.91.229.6 (25 Jan 2005 17:26:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Jan 2005 17:26:51 +0000 (UTC) Cc: sds@gnu.org, fx@gnu.org, wmperry@aventail.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 25 18:26:44 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CtUSi-00060j-00 for ; Tue, 25 Jan 2005 18:26:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CtUey-0002xg-Pr for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2005 12:39:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CtUbD-0000tn-62 for emacs-devel@gnu.org; Tue, 25 Jan 2005 12:35:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CtUbA-0000sy-94 for emacs-devel@gnu.org; Tue, 25 Jan 2005 12:35:29 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CtUYS-0008P8-FT for emacs-devel@gnu.org; Tue, 25 Jan 2005 12:32:40 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CtTuH-0007ON-6q; Tue, 25 Jan 2005 11:51:09 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id E1A2A8282B6; Tue, 25 Jan 2005 11:51:08 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id BAE734AC0B5; Tue, 25 Jan 2005 11:51:05 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A50624BB6A; Tue, 25 Jan 2005 11:51:05 -0500 (EST) Original-To: Klaus Straubinger In-Reply-To: (Klaus Straubinger's message of "Tue, 25 Jan 2005 15:32:06 +0100 (CET)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.765, requis 5, autolearn=not spam, AWL 0.14, BAYES_00 -4.90) X-MailScanner-From: monnier@iro.umontreal.ca X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:32548 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32548 > For me the patch provided a big improvement, but I still observed hangs - > as far as I could determine, always in connections without specified > Content-Length. I think the reason for this is that in these cases > url-http-simple-after-change-function is used which does not call the > callback function at the end, as opposed to > url-http-content-length-after-change-function. This leads to a hang in > accept-process-output when the connection already has been closed. OT1H, looking at the docstring of url-retrieve, I'd think that it's a bug in url-http.el that it sometimes fails to activate the callback. But, OTHO, looking at the url-http.el code it seems that it purposefully only activates the callback when the retrieval was successful. If someone could explain to me which it is, that would help. I guess what should really happen is that the callback is always activated but is given an extra argument (explicit or implicit) so it can tell whether the retrieval was successful. In any case, it might very well be that your problem is no related to all this but is a much more down to earth bug. To debug it, could you try to replace the (setq retrieval-done t) in your patch with (debug). Also do (setq url-debug '(http)). When the debugger gets called, take a look at the *URL-DEBUG* buffer (and send it here). > @@ -176,7 +176,7 @@ > ;; similar that takes processing completely outside of the URL > ;; package. > nil > - (while (not retrieval-done) > + (while (null retrieval-done) > (url-debug 'retrieval > "Spinning in url-retrieve-synchronously: %S (%S)" > retrieval-done asynch-buffer) not and null are synonyms. When to use which is a question of taste, but I tend to use `not' when applied to something that I consider as a boolean value, whereas I tend to use `null' when applied to something that can be nil or anything else (a list, for example). So in the above case, I think `not' is preferable. Stefan