* Fwd: Updating Inbox hangs (and I know why) [not found] <84fyp2x1hg.fsf@www.uni-magdeburg.de> @ 2005-12-14 15:12 ` Reiner Steib 2005-12-14 19:12 ` Simon Josefsson 0 siblings, 1 reply; 3+ messages in thread From: Reiner Steib @ 2005-12-14 15:12 UTC (permalink / raw) Cc: Wolfram Fenske [-- 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 ] ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Fwd: Updating Inbox hangs (and I know why) 2005-12-14 15:12 ` Fwd: Updating Inbox hangs (and I know why) Reiner Steib @ 2005-12-14 19:12 ` Simon Josefsson 2005-12-21 23:53 ` FIXED (was: Fwd: Updating Inbox hangs (and I know why)) Wolfram Fenske 0 siblings, 1 reply; 3+ messages in thread From: Simon Josefsson @ 2005-12-14 19:12 UTC (permalink / raw) Cc: Wolfram Fenske 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 ] ^ permalink raw reply [flat|nested] 3+ messages in thread
* FIXED (was: Fwd: Updating Inbox hangs (and I know why)) 2005-12-14 19:12 ` Simon Josefsson @ 2005-12-21 23:53 ` Wolfram Fenske 0 siblings, 0 replies; 3+ messages in thread From: Wolfram Fenske @ 2005-12-21 23:53 UTC (permalink / raw) Cc: Simon Josefsson 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-12-21 23:53 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <84fyp2x1hg.fsf@www.uni-magdeburg.de> 2005-12-14 15:12 ` Fwd: Updating Inbox hangs (and I know why) Reiner Steib 2005-12-14 19:12 ` Simon Josefsson 2005-12-21 23:53 ` FIXED (was: Fwd: Updating Inbox hangs (and I know why)) Wolfram Fenske
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).