From: Klaus Straubinger <KSNetz@Arcor.DE>
Subject: Re: url.el blocks Gnus+nnrss
Date: Wed, 26 Jan 2005 16:02:27 +0100 (CET) [thread overview]
Message-ID: <m38y6g5j3w.fsf@P131831.SAP.Corp> (raw)
In-Reply-To: <jwvu0p5o4by.fsf-monnier+emacs@gnu.org>
> 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 can't explain it.
Unfortunately, there is no good method to always react in the right
way, especially for these connections without specified Content-Length
where the only indicator is that the connection has been closed
already. As far as I know, there is no mechanism in Emacs that triggers
a function at connection-state changes. And how would you then classify
whether the retrieval has been successful?
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.
> To debug it, could you try to replace the (setq retrieval-done t) in
> your patch with (debug). Also do (setq url-debug '(http)).
OK, I have done that.
> When the debugger gets called, take a look at the *URL-DEBUG* buffer
> (and send it here).
Here it is:
http -> Cleaning up dead process: proxy:8080 #<process proxy>
http -> Cleaning up dead process: proxy:8080 #<process proxy>
http -> Contacting host: proxy:8080
http -> Marking connection as busy: proxy:8080 #<process proxy>
http -> Request is:
GET http://www.chesscenter.com/twic/twic.html HTTP/1.1
MIME-Version: 1.0
Connection: close
Extension: Security/Digest Security/SSL
Host: www.chesscenter.com
Accept-charset: utf-8;q=1, iso-8859-15;q=0.5, iso-8859-1;q=0.5, iso-8859-2;q=0.5, iso-8859-3;q=0.5, iso-8859-4;q=0.5, iso-8859-5;q=0.5, iso-8859-7;q=0.5, iso-8859-8;q=0.5, iso-8859-9;q=0.5, gb2312;q=0.5, euc-jp;q=0.5, euc-kr;q=0.5, iso-8859-14;q=0.5, big5;q=0.5, iso-2022-jp;q=0.5, koi8-r;q=0.5, shift_jis;q=0.5, viscii;q=0.5, hz-gb-2312;q=0.5, iso-2022-cn-ext;q=0.5, iso-2022-cn;q=0.5, iso-2022-jp-2;q=0.5, iso-2022-kr;q=0.5
Accept-language: de-DE, de, en-GB, en, it-IT, it, es-ES, es
Accept: */*
User-Agent: Emacs-W3/Exp URL/Emacs
http -> Calling after change function `url-http-wait-for-headers-change-function' for `#<process proxy>'
http -> url-http-wait-for-headers-change-function ( *http proxy:8080*<3>)
http -> Saw end of headers... ( *http proxy:8080*<3>)
http -> url-http-parse-response called in ( *http proxy:8080*<3>)
http -> No content-length, being dumb.
http -> Calling after change function `url-http-simple-after-change-function' for `#<process proxy>'
[...
many identical lines cut
...]
http -> Calling after change function `url-http-simple-after-change-function' for `#<process proxy>'
http -> url-http-end-of-document-sentinel in buffer ( *http proxy:8080*<3>)
http -> Marking connection as free: proxy:8080 #<process proxy>
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 #<process proxy>
http -> Activating callback in buffer ( *http proxy:8080*<3>)
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)
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.
> 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.
That sounds very reasonable.
--
Klaus Straubinger
next prev parent reply other threads:[~2005-01-26 15:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-13 12:16 url.el blocks Gnus+nnrss Katsumi Yamaoka
2005-01-13 14:35 ` Stefan Monnier
2005-01-13 22:39 ` Katsumi Yamaoka
2005-01-25 14:32 ` Klaus Straubinger
2005-01-25 16:51 ` Stefan Monnier
2005-01-26 15:02 ` Klaus Straubinger [this message]
2005-01-28 16:58 ` Stefan Monnier
2005-02-01 9:35 ` Klaus Straubinger
2005-01-28 23:16 ` Dave Love
2005-01-29 16:21 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m38y6g5j3w.fsf@P131831.SAP.Corp \
--to=ksnetz@arcor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).