nntp-accept-process-output's return value

nntp-accept-process-output's return value

[Stefan Monnier]

I Emacs's CVS repository, nntp-accept-process-output's ends as follows:

    (nnheader-accept-process-output process)
    ;; accept-process-output may update status of process to indicate
    ;; that the server has closed the connection.  This MUST be
    ;; handled here as the buffer restored by the save-excursion may
    ;; be the process's former output buffer (i.e. now killed)
    (or (and process
	     (memq (process-status process) '(open run)))
        (nntp-report "Server closed connection"))))

and in gnus-async-wait-for-article it is called as follows:

	    (while (eq article gnus-async-current-prefetch-article)
	      (incf tries)
	      (when (nntp-accept-process-output proc)
		(setq tries 0))
	      (when (and (not nntp-have-messaged)
			 (= tries 3))
		(gnus-message 5 "Waiting for async article...")
		(setq nntp-have-messaged t)))

so it seems that gnus-async-wait-for-article expects the function to return
a value indicating whether something was received or not.

My suspicion is that the last three lines of nntp-accept-process-output's
were added without paying attention to the fact that they affected the
return value.

So I suggest the patch below.  Does it sound right?


        Stefan


PS: The reason why I care is that I'm trying to track down some problem
  where my Gnus/IMAP sometimes "hangs" (C-g and then re-issuing the command
  generally fixes it).  I still don't have a good description of the problem
  nor a way to reproduce it, but it seemed that the code below may be
  related, although I don't have yet any evidence either way whether it
  fixes it or not.


--- orig/lisp/gnus/nntp.el
+++ mod/lisp/gnus/nntp.el
@@ -1316,22 +1316,21 @@
 
 (defun nntp-accept-process-output (process)
   "Wait for output from PROCESS and message some dots."
-  (save-excursion
-    (set-buffer (or (nntp-find-connection-buffer nntp-server-buffer)
-		    nntp-server-buffer))
+  (with-current-buffer (or (nntp-find-connection-buffer nntp-server-buffer)
+                           nntp-server-buffer)
     (let ((len (/ (buffer-size) 1024))
 	  message-log-max)
       (unless (< len 10)
 	(setq nntp-have-messaged t)
 	(nnheader-message 7 "nntp read: %dk" len)))
-    (nnheader-accept-process-output process)
+    (prog1 (nnheader-accept-process-output process)
     ;; accept-process-output may update status of process to indicate
     ;; that the server has closed the connection.  This MUST be
     ;; handled here as the buffer restored by the save-excursion may
     ;; be the process's former output buffer (i.e. now killed)
     (or (and process
 	     (memq (process-status process) '(open run)))
-        (nntp-report "Server closed connection"))))
+          (nntp-report "Server closed connection")))))
 
 (defun nntp-accept-response ()
   "Wait for output from the process that outputs to BUFFER."

Re: nntp-accept-process-output's return value

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> So I suggest the patch below.  Does it sound right?

Thanks for the patch; I've applied it to No Gnus v0.5 (i. e., CVS).
It seems to speculative to apply to Gnus 5.10 at the moment, I think. 

-- 
If you want an explanation on what you have just read, please
refer to <URL:http://quimby.gnus.org/gnus/zombie.html>.