<div dir="ltr">Hi, Sebastian<br><div><div class="gmail_extra"><br><div class="gmail_quote">2015-03-23 17:00 GMT+01:00 Sebastian Spaeth <span dir="ltr"><<a href="mailto:Sebastian@sspaeth.de" target="_blank">Sebastian@sspaeth.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We use a Queue in which all exiting threads are put() and loop around,<br>
waiting with .get(60) for one of those threads to finish.<br>
Queue().get(60) will wakeup every 50ms or so to see if the condition has<br>
been fulfilled. If you do not specify a timeout, there will be no<br>
wakeups, but the main thread will also not listen (and react) to<br>
signals, such as sent by CTRL-C (or SIGTERM). So we would run danger of<br>
hanging indefinitely and not be able to react on Ctrl-C.<br clear="all"></blockquote></div><br></div><div class="gmail_extra">Even though that's true, I've found that's not the one who is actively waiting.<br></div><div class="gmail_extra">I've applied attached patch and even though it's true that CTRL-C stops working, there's still threading.py code being executed, thouh I haven't found yet why.<br><br></div><div class="gmail_extra">I don't understand why is this, because latest call to <a href="http://threading.py/_Condition.wait()">threading.py/_Condition.wait()</a> is done with a timeout=None, but still gets busy on the following pasted lines of trace:<br><br> --- modulename: threading, funcname: wait<br>threading.py(235): print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ", timeout<br>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX None<br>threading.py(236): if not self._is_owned():<br> --- modulename: threading, funcname: _is_owned<br>threading.py(228): if self.__lock.acquire(0):<br>threading.py(232): return True<br>threading.py(238): waiter = _allocate_lock()<br>threading.py(239): waiter.acquire()<br>threading.py(240): self.__waiters.append(waiter)<br>threading.py(241): saved_state = self._release_save()<br> --- modulename: threading, funcname: _release_save<br>threading.py(220): self.__lock.release() # No state to save<br>threading.py(242): try: # restore state no matter what (e.g., KeyboardInterrupt)<br>threading.py(243): if timeout is None: <br>threading.py(244): waiter.acquire()<br>threading.py(255): while True:<br>threading.py(256): gotit = waiter.acquire(0)<br>threading.py(257): if gotit:<br>threading.py(259): remaining = endtime - _time()<br>threading.py(260): if remaining <= 0:<br>threading.py(262): delay = min(delay * 2, remaining, .05)<br>threading.py(263): _sleep(delay)<br><br></div><div class="gmail_extra">I placed a chunk of XXX to help me search on the trace and timeout is None. However, after line 244 it jumps to line 255, which is something I cannot comprehend.<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra">This test has been done with the following patch, which should have solved the busy waiting thing but doesn't, although breaks ctrl-c as predicted.<br></div><div class="gmail_extra"><br>diff --git a/offlineimap/threadutil.py b/offlineimap/threadutil.py<br>index f69f8a6..1d1fb84 100644<br>--- a/offlineimap/threadutil.py<br>+++ b/offlineimap/threadutil.py<br>@@ -109,7 +109,7 @@ def exitnotifymonitorloop(callback):<br> # we need a timeout in the get() call, so that ctrl-c can throw<br> # a SIGINT (<a href="http://bugs.python.org/issue1360" target="_blank">http://bugs.python.org/issue1360</a>). A timeout with empty<br> # Queue will raise `Empty`.<br>- thrd = exitthreads.get(True, 60)<br>+ thrd = exitthreads.get(True)<br> # request to abort when callback returns true<br> do_loop = (callback(thrd) != True)<br> except Empty:<br><br><br></div><div class="gmail_extra"><br>-- <br><div>Álvaro Gámez Machado<br></div>
</div></div></div>