interrupting nnimap doesn't really interrupt it

interrupting nnimap doesn't really interrupt it

[Rémi Letot]

Hello,

I'm using gnus to read gmane and imap mail. I recently switched to an
emacs23 snapshot, and noticed some problem with that version of gnus. I
don't know if it was already behaving like that before, and I can't
switch back to check as some internal data format has changed for
gnus. 

So to the weird behaviour : when I interrupt a time consuming task for
nnimap with C-g (like expiring mail in a big nnimap group) with C-g, it
seems nnimap continues the operation in the background. I can't use any
nnimap operation as long as it has not finished what it was doing. So
for example hitting g to refresh my groups will hang when it tries to
get info from nnimap. Entering an imap group will hang as well,...

Is this the expected behaviour ?

Thanks,
-- 
Rémi

Re: interrupting nnimap doesn't really interrupt it

[Steinar Bang]

>>>>> hobbes@poukram.net (Rémi Letot):

> So to the weird behaviour : when I interrupt a time consuming task for
> nnimap with C-g (like expiring mail in a big nnimap group) with C-g,
> it seems nnimap continues the operation in the background. I can't use
> any nnimap operation as long as it has not finished what it was
> doing. So for example hitting g to refresh my groups will hang when it
> tries to get info from nnimap. Entering an imap group will hang as
> well,...

Try going to the buffer " *nnimap* yourserverthathadproblems" (note the
leading space on the buffer name), and kill that buffer.

Then go back to the *Group* buffer and test to see if the `g' command
works normally.

I see this problem occasionally when I forget to unplug Gnus before
putting my laptop to sleep, and then wakening it in a different network
(eg. from work to home).

Re: interrupting nnimap doesn't really interrupt it

[Vitaly Mayatskikh]

At Sat, 15 Nov 2008 22:30:16 +0100, Rémi Letot wrote:

> I'm using gnus to read gmane and imap mail. I recently switched to an
> emacs23 snapshot, and noticed some problem with that version of gnus. I
> don't know if it was already behaving like that before, and I can't
> switch back to check as some internal data format has changed for
> gnus. 
> 
> So to the weird behaviour : when I interrupt a time consuming task for
> nnimap with C-g (like expiring mail in a big nnimap group) with C-g, it
> seems nnimap continues the operation in the background. I can't use any
> nnimap operation as long as it has not finished what it was doing. So
> for example hitting g to refresh my groups will hang when it tries to
> get info from nnimap. Entering an imap group will hang as well,...
> 
> Is this the expected behaviour ?

Try to kill a process with imap-ssl-program (usually, openssl or gnutls-cli)
--
wbr, Vitaly

using dbus to unplug gnus (was: Re: interrupting nnimap doesn't really interrupt it)

[Dan Nicolaescu]

Steinar Bang <sb@dod.no> writes:

  > >>>>> hobbes@poukram.net (Rémi Letot):
  > 
  > > So to the weird behaviour : when I interrupt a time consuming task for
  > > nnimap with C-g (like expiring mail in a big nnimap group) with C-g,
  > > it seems nnimap continues the operation in the background. I can't use
  > > any nnimap operation as long as it has not finished what it was
  > > doing. So for example hitting g to refresh my groups will hang when it
  > > tries to get info from nnimap. Entering an imap group will hang as
  > > well,...
  > 
  > Try going to the buffer " *nnimap* yourserverthathadproblems" (note the
  > leading space on the buffer name), and kill that buffer.
  > 
  > Then go back to the *Group* buffer and test to see if the `g' command
  > works normally.
  > 
  > I see this problem occasionally when I forget to unplug Gnus before
  > putting my laptop to sleep, and then wakening it in a different network
  > (eg. from work to home).

This sounds exactly like the problem the dbus support included in emacs
CVS could solve: you could ask to receive an event for going to sleep,
and unplug gnus when that event is received.  (Note that I've never done
the above, but it sounds doable from the description of what dbus can
do.)
Just my 2 cents.