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: Fri, 28 Jan 2005 11:58:41 -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 1106931603 11869 80.91.229.6 (28 Jan 2005 17:00:03 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 28 Jan 2005 17:00:03 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 28 17:59:45 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 1CuZTF-0007T2-00 for ; Fri, 28 Jan 2005 17:59:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CuZfe-00064X-BZ for ged-emacs-devel@m.gmane.org; Fri, 28 Jan 2005 12:12:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CuZf4-0005uN-QX for emacs-devel@gnu.org; Fri, 28 Jan 2005 12:11:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CuZf2-0005tS-K1 for emacs-devel@gnu.org; Fri, 28 Jan 2005 12:11:57 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CuZf2-0005tG-Ds for emacs-devel@gnu.org; Fri, 28 Jan 2005 12:11:56 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CuZSI-0002rP-6m for emacs-devel@gnu.org; Fri, 28 Jan 2005 11:58:47 -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 8D3718282AE; Fri, 28 Jan 2005 11:58:45 -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 5E4114AC0B5; Fri, 28 Jan 2005 11:58:41 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id 457C64C20C; Fri, 28 Jan 2005 11:58:41 -0500 (EST) Original-To: Klaus Straubinger In-Reply-To: (Klaus Straubinger's message of "Wed, 26 Jan 2005 16:02:27 +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.77, requis 5, autolearn=not spam, AWL 0.13, 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:32609 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32609 > As far as I know, there is no mechanism in Emacs that triggers > a function at connection-state changes. See set-process-sentinel ;-) > I think most of the complexity of the URL package comes from the fact > that it implements asynchronous fetching of data. This feature is not > necessary for my usage pattern, but obviously the author thought the > complexity worthwile. Actually, Emacs does not provide any direct support for synchronous "open-connection/send-data/read-data", the way it does for processes with `call-process'. So the author (William Perry) had no choice, really. Furthermore, given the complexity of HTTP (with authentication and stuff), it's basically impossible for Emacs to provide a synchronous API that would be usable for HTTP. > Here it is: > http -> Cleaning up dead process: proxy:8080 # Hmm... so you're going through a proxy, good to know. > many identical lines cut > ...] > http -> Calling after change function `url-http-simple-after-change-function' for `#' > http -> url-http-end-of-document-sentinel in buffer ( *http proxy:8080*<3>) > http -> Marking connection as free: proxy:8080 # > http -> url-http-parse-headers called in ( *http proxy:8080*<3>) > http -> url-http-parse-response called in ( *http proxy:8080*<3>) > http -> Parsed HTTP headers: class=2 status=200 > http -> Finished parsing HTTP headers: t > http -> Marking connection as free: proxy:8080 # > http -> Activating callback in buffer ( *http proxy:8080*<3>) So the sentinel is properly called when the connection is closed and it does activate "the" callback. Now why didn't the callback set `retrieval-done'? > The debugger backtrace looks like this, exactly as one would expect: > (if (eq (process-status proc) (quote closed)) (debug) (if (accept-process-output proc) nil (setq proc ...))) > (while (not (symbol-value --retrieval-done--30970)) (url-debug (quote retrieval) "Spinning in url-retrieve-synchronously: %S (%S)" (symbol-value --retrieval-done--30970) (symbol-value --asynch-buffer--30971)) (if (eq ... ...) (debug) (if ... nil ...))) > (if (null proc) nil (while (not ...) (url-debug ... "Spinning in url-retrieve-synchronously: %S (%S)" ... ...) (if ... ... ...))) > (let ((proc ...)) (if (null proc) nil (while ... ... ...))) > (progn (set --asynch-buffer--30971 (url-retrieve url ...)) (let (...) (if ... nil ...)) (symbol-value --asynch-buffer--30971)) > (let ((--retrieval-done--30970 ...) (--asynch-buffer--30971 ...)) (setf (symbol-value --retrieval-done--30970) nil (symbol-value --asynch-buffer--30971) nil) (progn (set --asynch-buffer--30971 ...) (let ... ...) (symbol-value --asynch-buffer--30971))) > (lexical-let ((retrieval-done nil) (asynch-buffer nil)) (setq asynch-buffer (url-retrieve url ...)) (let (...) (if ... nil ...)) asynch-buffer) > url-retrieve-synchronously("http://WWW.ChessCenter.Com/twic/twic.html") > eval((url-retrieve-synchronously "http://WWW.ChessCenter.Com/twic/twic.html")) > eval-expression((url-retrieve-synchronously "http://WWW.ChessCenter.Com/twic/twic.html") nil) > call-interactively(eval-expression) Could you in the *Backtrace* buffer check the value of the following expressions (and post them here), using `e': proc (process-buffer proc) (with-current-buffer (process-buffer proc) url-callback-function) --retrieval-done--30970 (symbol-value --retrieval-done--30970) The "30970" might change from one run to the other, so check the backtrace to see which number was used that time. > 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 men 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)))))) -- Stefan