>>>>> Simon Josefsson wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> (while (and (memq (process-status PROCESS) '(open run))
>>             (wait-for-a-string-that-the-PROCESS-returns))
>>   (accept-process-output PROCESS 1)
>>   (sit-for 1))
>>
>> This can be an infinite loop if the process-status keeps `open'
>> or `run' even though the connection has actually died.

> Can that happen?  Wouldn't that be an emacs bug?  Shouldn't
> process-status return exit or closed if a connect/process has gone away?

I meant that the /connection/ is the one between the frontend of
Ted Zlatanov's local network (i.e., VPN) and the IMAP server (see
http://article.gmane.org/gmane.emacs.gnus.general/64906).  In his
case, the connection between Emacs and the frontend seems to be
alive even after the connection between the frontend and the IMAP
server dies.  So, ideally, what needs to be fixed should be
the VPN program, not be Emacs or Gnus, I think, and the plan I
proposed was no more than a workaround.  But I thought it was not
necessarily a bad idea even if the problem in the VPN program can
be solved soon, because people in the VPN networks might not
necessarily be able to ask the administrators to replace the
program with the corrected one.

>> In particular, the `imap-wait-for-tag' function can be the cause of
>> the hanging since it sends the LOGOUT command to the dead server and
>> waits for the response.  So, I tried modifying it so as to quit in a
>> certain time.  The patch to imap.el is below.  Anyway, it needs to be
>> reviewed by someone who is skilled in IMAP.  The default value of
>> `imap-timeout-seconds' might be too small for slow connections.

[...]

> This is a bad idea even for fast servers -- some operations (such as
> deleting or renaming a mailabox) can take several minutes.  Gnus
> shouldn't assume the server isn't responding in this (and other) cases.

Ok, but I didn't know it.

> Ted Zlatanov <tzz@lifelogs.com> writes:

>> Maybe it should be generalized, however, to an IMAP timeout per (server,
>> group name, command) combination (as a regex or a function), so you can
>> assign "LOGOUT" a longer timeout with a slower server.  This could also
>> be a server tuning parameter for nnimap instead of an imap.el parameter.

> Having the timeout be restricted to just LOGOUT seems to make more sense
> to me.  If the server doesn't respond to a LOGOUT within a short period
> of time, one might as well disconnect.

I see.  It looks sufficient for Ted.

>>>>> Reiner Steib wrote:
> On Tue, Jul 31 2007, Katsumi Yamaoka wrote:

>> +(defvar imap-timeout-seconds 1
>> +  "*Number of seconds in which `imap-close' gives up working.")

> Nitpick: Either the "*" should be removed or it should be a defcustom.
> Shouldn't it?

I agree to making it use defcustom.  In addition, a good default
will probably be the value meaning there's no timeout.  Anyway I
use neither nnimap nor VPN at all, and I can neither reproduce
the problem nor verify this workaround.  So, I wish Simon and Ted
to take on this.