From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Klaus Straubinger Newsgroups: gmane.emacs.devel Subject: Re: url.el blocks Gnus+nnrss Date: Tue, 1 Feb 2005 10:35:35 +0100 (CET) Message-ID: References: <87pt09v2m1.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1107250912 31083 80.91.229.2 (1 Feb 2005 09:41:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2005 09:41:52 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 10:41:52 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CvuXS-0005IE-1O for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2005 10:41:39 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CvukL-0008DM-5r for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2005 04:54:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cvuji-0008AD-W4 for emacs-devel@gnu.org; Tue, 01 Feb 2005 04:54:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cvujf-00087Z-3w for emacs-devel@gnu.org; Tue, 01 Feb 2005 04:54:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cvuje-00081j-87 for emacs-devel@gnu.org; Tue, 01 Feb 2005 04:54:14 -0500 Original-Received: from [155.56.68.170] (helo=smtpde02.sap-ag.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CvuRc-0007Ua-Cw for emacs-devel@gnu.org; Tue, 01 Feb 2005 04:35:36 -0500 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id KAA16097 for ; Tue, 1 Feb 2005 10:35:33 +0100 (MEZ) Original-To: emacs-devel@gnu.org In-Reply-To: X-Mailer: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 X-SAP: out 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:32695 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32695 > Could you in the *Backtrace* buffer check the value of the following > expressions (and post them here), using `e': > > proc # > (process-buffer proc) nil (because url-http-activate-callback already has called url-http-mark-connection-as-free which resets the process buffer) > (with-current-buffer (process-buffer proc) url-callback-function) After replacing the nil value of (process-buffer proc) with " *http proxy:8080*": (lambda (&rest --cl-rest--) (apply (quote (lambda (G96930 G96931 &rest ignored) (url-debug (quote retrieval) "Synchronous fetching done (%S)" (current-buffer)) (progn (set G96931 t) (set G96930 (current-buffer))))) (quote --asynch-buffer--) (quote --retrieval-done--) --cl-rest--)) > --retrieval-done--30970 Symbol's value as variable is void: --retrieval-done--96924 > (symbol-value --retrieval-done--30970) ... is t at least later on in the debugger, although I have not been able to evaluate it with the "e" command. >> By the way, I have observed also hangs at redirects, where another >> url-retrieve is called when the old connection could still receive >> data. (accept-process-output url-http-process) directly before the new >> url-retrieve did help, but I have no clue why. > > Could you show a patch of the actual change you tried? > Do you mean just before `url-retrieve' in url-http-parse-headers > in the lines: > > (let ((url-request-method url-http-method) > (url-request-data url-http-data) > (url-request-extra-headers url-http-extra-headers)) > (url-retrieve redirect-uri url-callback-function > url-callback-arguments) > (url-mark-buffer-as-dead (current-buffer)))))) Yes, exactly. There I threw in a (accept-process-output url-http-process) just because it seemed to help. Unfortunately, I don't see why. -- Klaus Straubinger