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, 25 Jan 2005 15:32:06 +0100 (CET) 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 1106664831 17854 80.91.229.6 (25 Jan 2005 14:53:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Jan 2005 14:53:51 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 25 15:53:19 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 1CtS4F-0005u2-00 for ; Tue, 25 Jan 2005 15:53:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CtSGV-0005p7-3s for ged-emacs-devel@m.gmane.org; Tue, 25 Jan 2005 10:05:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CtSCY-0004DO-SJ for emacs-devel@gnu.org; Tue, 25 Jan 2005 10:01:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CtSCR-00048Y-0U for emacs-devel@gnu.org; Tue, 25 Jan 2005 10:01:47 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CtSCM-00044M-Cz for emacs-devel@gnu.org; Tue, 25 Jan 2005 10:01:42 -0500 Original-Received: from [155.56.68.170] (helo=smtpde02.sap-ag.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CtRjj-0000lW-QF for emacs-devel@gnu.org; Tue, 25 Jan 2005 09:32:08 -0500 Original-Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA05793 for ; Tue, 25 Jan 2005 15:32:05 +0100 (MEZ) Original-To: emacs-devel@gnu.org In-Reply-To: <87pt09v2m1.fsf-monnier+emacs@gnu.org> 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 Xref: main.gmane.org gmane.emacs.devel:32547 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32547 > I've myself been using the patch below for a while now (it basically does > the same as yours, except it hoists the get-buffer-process outside the loop > and it removes the timeout since it shouldn't be needed now that Emacs knows > what we're waiting for). > > I've just installed it. 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. The following patch did help me, although I am not sure if it is the right way to tackle the problem: --- url.el.orig 2005-01-14 13:36:36.000000000 +0100 +++ url.el 2005-01-25 14:47:52.325350728 +0100 @@ -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) @@ -185,11 +185,13 @@ ;; interrupt it before it got a chance to handle process input. ;; `sleep-for' was tried but it lead to other forms of ;; hanging. --Stef - (unless (accept-process-output proc) - ;; accept-process-output returned nil, maybe because the process - ;; exited (and may have been replaced with another). - (setq proc (get-buffer-process asynch-buffer))))) - asynch-buffer))) + (if (eq (process-status proc) 'closed) + (setq retrieval-done t) + (unless (accept-process-output proc) + ;; accept-process-output returned nil, maybe because the process + ;; exited (and may have been replaced with another). + (setq proc (get-buffer-process asynch-buffer))))))) + asynch-buffer)) (defun url-mm-callback (&rest ignored) (let ((handle (mm-dissect-buffer t))) -- Klaus Straubinger