#3 Can't interrupt IDLE with Control-C

[Dave Abrahams]

For me, KeyboardInterrupts don't come out of calls to idle() in a timely fashion. It might be waiting for my timeout. I'm going to try idling in a thread and waiting on a CV set by that thread (with a timeout; see http://bugs.python.org/issue8844), but it seems to me that the library should handle this for me.

[Piers Lauder]

When I set up an IDLE, and then hit CTRL-C, it exits immediately. So I'm not sure how this behaviour comes about. To test it, I added this code at line 2453 in imaplib2.py:

        M._mesg('HIT CTRL-C to interrupt IDLE')
        run('idle', (99,), cb=False) # Synchronous, to test interruption of 'idle' by INTR

and ran "python imaplib2.py -s ..."

Perhaps you could write a minimal script that exhibits the problem you are seeing, and then I can dig deeper.

Piers Lauder

[Dave Abrahams]

Apologies; I don't think it's imaplib2's problem. I had a timer running that wasn't being cancelled, and it was keeping the process alive.

[Tim Peoples]

It appears that this is still an issue when using Python-2.x (at least with the python 2.7.6 installed on my Trusty host). IOW: on a somewhat stock install of Ubuntu-14.04, running the imaplib2 "-i" test using python2 shows that IDLE calls cannot be interrupted using a KeyboardInterrupt.

The original submitter had it right when he mentioned python issue #8844 which has been fixed in Python-3.x for quite a while, but doesn't look like it will ever be fixed in python-2.x. This problem involves calling threading.Event.wait() without a timeout value. If no timeout is given, then the call to wait() seems to be uninterruptible. imaplib2 does this in two places.

The fix, of course, is to provide a timeout value when calling wait()... and, since wait() wants a float value, it seems reasonable to use sys.float_info.max (which, according to my math, is equivalent to enough seconds to wait until the heat death of the universe (given a 64bit float value)).

I have a patch available for this fix but I'm not sure how to submit it. Then again, it's a two line change so I doubt a patch is really warranted.. but, I'll be happy to submit one nonetheless (as soon as I know how).

Finally... I'm not much of a sourceforge user so I do hope that by commenting on this bug I actually reopen the issue. If not, I guess I'll open another one instead.

[Tim Peoples]

Make that "-i" instead of "-t"... but, you get the idea. :D

[Piers Lauder]

I have duplicated your result, so yes, please submit your two line patch! (just lines of text in this interface will do.)

Thanks!

[Tim Peoples]

Here ya go!

:D

diff --git a/imaplib2.py b/imaplib2.py
index 6641741..4fd04e6 100755
--- a/imaplib2.py
+++ b/imaplib2.py
@@ -183,7 +183,7 @@ class Request(object):
def get_response(self, exc_fmt=None):
self.callback = None
if debug: self.parent._log(3, '%s:%s.ready.wait' % (self.name, self.tag))
- self.ready.wait(sys.float_info.max)
+ self.ready.wait()

     if self.aborted is not None:
         typ, val = self.aborted

@@ -1306,7 +1306,7 @@ class IMAP4(object):
self.commands_lock.release()
if need_event:
if debug: self._log(3, 'sync command %s waiting for empty commands Q' % name)
- self.state_change_free.wait(sys.float_info.max)
+ self.state_change_free.wait()
if debug: self._log(3, 'sync command %s proceeding' % name)

     if self.state not in Commands[name][CMD_VAL_STATES]:

[Tim Peoples]

(oops... sorry... that patch was backwards. I hope you get the idea)

[Piers Lauder]

Thanks. Works. New version uploaded.