Fwd: Updating Inbox hangs (and I know why)

Fwd: Updating Inbox hangs (and I know why)

[Reiner Steib]

[-- Attachment #1: Type: text/plain, Size: 119 bytes --]

[ From bugs@gnus.org ... ]

Hi,

I don't know if this should be fixed in imap.el or in XEmacs.

Anyone?

Bye, Reiner.


[-- Attachment #2: Type: message/rfc822, Size: 2007 bytes --]

From: Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE>
Subject: Updating Inbox hangs (and I know why)
Date: Fri, 09 Dec 2005 06:50:51 +0100
Message-ID: <84fyp2x1hg.fsf@www.uni-magdeburg.de>


Hello!

When I try to update my Inbox (M-g) after a period of inactivity (say
5 or 10 minutes), XEmacs hangs. I have to press C-g to stop updating. 
Pressing M-g afterwards opens a new connection and succeeds. I think 
what happens is that the connection somehow dies while I'm not active 
but Gnus somehow doesn't realize this.


I have found out that the hanging occurs in "imap-wait-for-tag" in
"imap.el". The function call that hangs is "(accept-process-output
imap-process 0 0)". Now I'm not really sure what this is supposed to
do, but I suspect this is a bug because looking at the definition of
"accept-process-output" in XEmacs' "event-stream.c" if find this:

  if (msecs)
    {
      timeout_id = event_stream_generate_wakeup (msecs, 0, Qnil, Qnil, 0);
      timeout_enabled = 1;
    }

That means that a timeout is only established if the given interval is
non-zero. So in the case of "(accept-process-output imap-process 0
0)", it waits indefinitely if not output is generated. But if the
process is dead, "(memq (process-status imap-process) '(open run))" in
the while loop above returns "nil" and we get to the function call in
question and never return.

I tried and set the timeout to 1 second. This way, when I update and
the imap-process has died, I get an error the first time:

  Process not open for writing: #<process "imap" pid 1400 state:exit>

If I try it again, updating works. I guess what's needed is to restart 
the process if it's not open or running anymore.

Kind regards
Wolfram Fenske


Gnus v5.10.7
XEmacs 21.4 (patch 17) "Jumbo Shrimp" [Lucid] (i686-pc-cygwin, Mule) of Fri Nov  4 2005 on hondo
201 news.cs.uni-magdeburg.de InterNetNews NNRP server INN 2.4.1 ready (no posting).



[-- Attachment #3: Type: text/plain, Size: 96 bytes --]



[ User settings stripped, see
  <news:84fyp2x1hg.fsf@www.uni-magdeburg.de> on news.gnus.org ]

Re: Fwd: Updating Inbox hangs (and I know why)

[Simon Josefsson]

I think this is an XEmacs problem.  Calling accept-process-output on a
dead process should return an error.  There may be an imap.el bug too,
or a imap.el workaround, but if XEmacs detected if a process had died
when accept-process-output, the exact bug below would probably not
occur.

Reiner Steib <reinersteib+from-uce@imap.cc> writes:

> [ From bugs@gnus.org ... ]
>
> Hi,
>
> I don't know if this should be fixed in imap.el or in XEmacs.
>
> Anyone?
>
> Bye, Reiner.
>
> From: Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE>
> Subject: Updating Inbox hangs (and I know why)
> Newsgroups: gnus.gnus-bug
> Date: Fri, 09 Dec 2005 06:50:51 +0100
>
>
> Hello!
>
> When I try to update my Inbox (M-g) after a period of inactivity (say
> 5 or 10 minutes), XEmacs hangs. I have to press C-g to stop updating. 
> Pressing M-g afterwards opens a new connection and succeeds. I think 
> what happens is that the connection somehow dies while I'm not active 
> but Gnus somehow doesn't realize this.
>
>
> I have found out that the hanging occurs in "imap-wait-for-tag" in
> "imap.el". The function call that hangs is "(accept-process-output
> imap-process 0 0)". Now I'm not really sure what this is supposed to
> do, but I suspect this is a bug because looking at the definition of
> "accept-process-output" in XEmacs' "event-stream.c" if find this:
>
>   if (msecs)
>     {
>       timeout_id = event_stream_generate_wakeup (msecs, 0, Qnil, Qnil, 0);
>       timeout_enabled = 1;
>     }
>
> That means that a timeout is only established if the given interval is
> non-zero. So in the case of "(accept-process-output imap-process 0
> 0)", it waits indefinitely if not output is generated. But if the
> process is dead, "(memq (process-status imap-process) '(open run))" in
> the while loop above returns "nil" and we get to the function call in
> question and never return.
>
> I tried and set the timeout to 1 second. This way, when I update and
> the imap-process has died, I get an error the first time:
>
>   Process not open for writing: #<process "imap" pid 1400 state:exit>
>
> If I try it again, updating works. I guess what's needed is to restart 
> the process if it's not open or running anymore.
>
> Kind regards
> Wolfram Fenske
>
>
> Gnus v5.10.7
> XEmacs 21.4 (patch 17) "Jumbo Shrimp" [Lucid] (i686-pc-cygwin, Mule) of Fri Nov  4 2005 on hondo
> 201 news.cs.uni-magdeburg.de InterNetNews NNRP server INN 2.4.1 ready (no posting).
>
>
> ----------
>
>
>
> [ User settings stripped, see
>   <news:84fyp2x1hg.fsf@www.uni-magdeburg.de> on news.gnus.org ]

FIXED (was: Fwd: Updating Inbox hangs (and I know why))

[Wolfram Fenske]

Hello!

I have figured out a solution now: when imap-wait-for-tag discovers that the imap process has exited, it throws an exception. nnimap-request-update-info-internal catches it. If an exception occurred, nnimap-request-update-info-internal closes the current connection, opens a new one and starts itself again. If no exception occurred, it behaves as usual.

Here's what I did to imap.el, revision 1.26:

1810a1811,1812
>       (unless (memq (process-status imap-process) '(open run))
>           (throw :process-dead :process-dead))

and to nnimap.el, revision 1.29:

1119c1119
< (deffoo nnimap-request-update-info-internal (group info &optional server)
---
> (deffoo nnimap-request-update-info-internal-1 (group info &optional server)
1180a1181,1191
> (deffoo nnimap-request-update-info-internal (group info &optional server)
>   (let ((main (lambda () (nnimap-request-update-info-internal-1 
>                         group info server))))
>     (let ((result (catch :process-dead (funcall main))))
>       (if (eql result :process-dead)
>         (with-current-buffer nnimap-server-buffer
>           (nnimap-close-server server)
>           (nnimap-open-connection server)
>           (funcall main))
>       result))))
> 

This patch makes nnimap do exactly what I want it to: use the current connection if possible and open a new one if it died. Maybe my solution isn't a clean way to do that, but so far, it seems to work OK.

I still have some related problems, though. E.g. when I exit the summar buffer after longer period of time, my exception from imap.el also gets thrown but naturally isn't caught. I suppose this function has the same problem as nnimap-request-update-info-internal and could be fixed in the same way.

It's interesting that the imap process can still be alive at the beginning of nnimap-request-update-info-internal but be dead in imap-wait-for-tag, which is called by nnimap-request-update-info-internal. I guess what happens is that the server silently closes the connection, but gnutls-cli (yes, I use gnutls-cli) doesn't notice it until it tries to communicate with the server again. And when it does notice it, the imap process/gnutls-cli dies. I would like to reopen the connection directly in imap-wait-for-tag, but can't, because other functions don't realize that the process handle has changed (or something to that effect). That's why I used exceptions to do it.

What do you think? If I can help you with this issue I'd be happy to do so.

Regards
Wolfram Fenske