From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53341 Path: main.gmane.org!not-for-mail From: Gaute B Strokkenes Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap versus tls Date: Mon, 07 Jul 2003 10:46:28 +0100 Organization: The Church of Emacs Sender: ding-owner@lists.math.uh.edu Message-ID: <87el12lle3.fsf@cam.ac.uk> References: <87ptmfhxj6.fsf@cam.ac.uk> <84of0ab15z.fsf@lucy.is.informatik.uni-duisburg.de> <87k7axwef3.fsf@cam.ac.uk> <843chlyw19.fsf@lucy.is.informatik.uni-duisburg.de> <87adbrq0dy.fsf@cam.ac.uk> <84he5z4pne.fsf@lucy.is.informatik.uni-duisburg.de> <873chjtj8o.fsf@cam.ac.uk> <848yraamxb.fsf@lucy.is.informatik.uni-duisburg.de> <873chiiyqu.fsf@cam.ac.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1057571231 22840 80.91.224.249 (7 Jul 2003 09:47:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 7 Jul 2003 09:47:11 +0000 (UTC) Original-X-From: ding-owner+M1885@lists.math.uh.edu Mon Jul 07 11:47:09 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19ZSaS-0005w1-00 for ; Mon, 07 Jul 2003 11:47:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ZSaY-0005u4-00; Mon, 07 Jul 2003 04:47:14 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ZSaT-0005tz-00 for ding@lists.math.uh.edu; Mon, 07 Jul 2003 04:47:09 -0500 Original-Received: (qmail 82369 invoked by alias); 7 Jul 2003 09:47:09 -0000 Original-Received: (qmail 82364 invoked from network); 7 Jul 2003 09:47:09 -0000 Original-Received: from mta01-svc.ntlworld.com (62.253.162.41) by sclp3.sclp.com with SMTP; 7 Jul 2003 09:47:09 -0000 Original-Received: from belldandy ([81.100.93.186]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20030707094706.NOWR21249.mta01-svc.ntlworld.com@belldandy> for ; Mon, 7 Jul 2003 10:47:06 +0100 Original-Received: from gs234 by belldandy with local (Exim 3.36 #1 (Debian)) id 19ZSZo-00037p-00 for ; Mon, 07 Jul 2003 10:46:28 +0100 Mail-Copies-To: never Original-To: ding@gnus.org Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEWWWBTly7aGMwb+/vz9 +ffIilb///+yaCxNCwHGVC3gAAACU0lEQVR4nF2TQWvjMBBGVUGwj3WxaY/aAWNfi0zuwZPuHp0Q ob079OwYjHrsChb0s3dGctJ0ddTzm9F8lsR7WiNiWWL/flviul9Uh0NR4vY/gJUxJjOEtt/AubBy UsotRfH2DbxWE0hom3w5XJUEKis9hACt2hR4B86VDOtqTNHfgeEGvLiUN7Ddze26Dx6y1CUa+ygo NwFQm0N/BeMzCZAtNIoQrd9EhcH5mWpnztB8ZpJBlH23jaAbuE4EhZ2Bam0TeJ0DRMCKVP6CegWk q4z2TVFUx0946FOPcSe9ELE3rSHAj15rBuddS0C4BGyAutfpVAQkKdZOQiwMMIHxlUDrgeej5Ns7 I/ccSWNBLda1XwYBEG1Qswy1yXJf879nA4cjkNI0H+FzoUyuRodPA5eqZwFONG34i30ccOxeKFUy flNe1szqsgLdvXwKCj6zjTXODHV9M46gZPCLlYKCGTYO8S0aOAvJzRfD0w+1XcGIsxLUw/sYl5sM 9n0yjkoSUDOByrijwRRiAq13NhqLJYB3ACazrgN2bIwanyJQKXhHAJPRPQruEaCJP2Shy4DJ2As+ FQjJZH7AZIy6w0pQiiRYAh8nTEZHYDfRqSDeB5OXq4EEcAC4NocvoBl4+n1cyl54nyLRNA3iIwRP wNGFOK1g1Gz8jNfaCjdtqJLm2LXuqMc+50cDIJQpr6X0OHa4X58ULAw03QbRd7GUiG/K04mj0bNB xQhwJkEsJiZ1Bbgb6CnF79cBE+jwF91qniOCP3fghUFKxOShjIATw/wOfIQTg39LpFHtxhlKywAA AABJRU5ErkJggg== In-Reply-To: <873chiiyqu.fsf@cam.ac.uk> (Gaute B. Strokkenes's message of "Mon, 07 Jul 2003 08:26:17 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53341 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53341 On 7 jul 2003, gs234@cam.ac.uk wrote: > On 7 jul 2003, kai.grossjohann@gmx.net wrote: >> Gaute B Strokkenes writes: >> >>> I believe that what is going on is that in one iteration of the >>> loop, we receive the server's last bit of output after >>> accept-process-output has returned, but before we test the loop >>> condition. That way, (process-status imap-process) will be 'exit; >>> but there will still be output waiting for us that we haven't >>> taken care of yet. Everything will appear to work swimmingly >>> until Emacs is about to idle, and it checks for process output >>> again. >> >> Okay, then another accept-process-output after the loop ought to >> take care of it. Right? >> >> Gnah. I feel so silly with this stupid kind of advice :-/ >> I wished I grokked this. [snip] > So we seem to have guessed correctly at last. ^_^ > > I'll prepare a (nicer-looking) patch... Well, I now have _two_ patches. The first one is the stripped down version of what you've already seen: Index: imap.el =================================================================== RCS file: /usr/local/cvsroot/gnus/lisp/imap.el,v retrieving revision 6.52 diff -u -r6.52 imap.el --- imap.el 20 Apr 2003 13:44:27 -0000 6.52 +++ imap.el 7 Jul 2003 09:16:34 -0000 @@ -1754,6 +1754,13 @@ (truncate (* (- imap-read-timeout (truncate imap-read-timeout)) 1000))))) + (when (and (null imap-continuation) + (< imap-reached-tag tag)) + (accept-process-output imap-process + (truncate imap-read-timeout) + (truncate (* (- imap-read-timeout + (truncate imap-read-timeout)) + 1000)))) (when imap-have-messaged (message "")) (and (memq (process-status imap-process) '(open run)) Basically, if we quit the loop due to (process-status imap-process) no longer being open or run, then we do the accept-process-output thingie again. This isn't very pretty, but it's the minimally-intrusive, maximally safe fix. The other version: Index: imap.el =================================================================== RCS file: /usr/local/cvsroot/gnus/lisp/imap.el,v retrieving revision 6.52 diff -u -r6.52 imap.el --- imap.el 20 Apr 2003 13:44:27 -0000 6.52 +++ imap.el 7 Jul 2003 09:18:30 -0000 @@ -1740,15 +1740,19 @@ (defun imap-wait-for-tag (tag &optional buffer) (with-current-buffer (or buffer (current-buffer)) - (let (imap-have-messaged) + (let (imap-have-messaged + (imap-more-coming t)) (while (and (null imap-continuation) - (memq (process-status imap-process) '(open run)) + imap-more-coming +; (memq (process-status imap-process) '(open run)) (< imap-reached-tag tag)) (let ((len (/ (point-max) 1024)) message-log-max) (unless (< len 10) (setq imap-have-messaged t) (message "imap read: %dk" len)) + (setq imap-more-coming + (memq (process-status imap-process) '(open run))) (accept-process-output imap-process (truncate imap-read-timeout) (truncate (* (- imap-read-timeout The idea was to have a flag that tells us when there's no more data coming out of imap-process. By only updating the flag just before we do an accept-process-output, we ensure that we have always read all that there is to read before we stop. And this works. At least, half the time it does. The other half Gnus seems to hang while EXAMINE-ing my nnimap:mail/received folder. I can't quite figure out what's going wrong, since setting debug-on-quit to t and/or adding trivial debug code seems to cause the hang to go away. I vaguely suspect that this is some sort of bad timing/scheduling interaction between Emacs and gnutls-cli, but I have no idea how to test that hypothesis. In any case, I believe we've found the bug. I'll leave it to someone who understands what's going on to actually fix it... -- Gaute Strokkenes http://www.srcf.ucam.org/~gs234/ TAPPING? You POLITICIANS! Don't you realize that the END of the ``Wash Cycle'' is a TREASURED MOMENT for most people?!