Re: url.el blocks Gnus+nnrss

[Stefan Monnier]

> 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