Active waiting?

[Alvaro Gamez]

Hi, Sebastian

2015-03-23 17:00 GMT+01:00 Sebastian Spaeth <Sebastian at sspaeth.de>:

> We use a Queue in which all exiting threads are put() and loop around,
> waiting with .get(60) for one of those threads to finish.
> Queue().get(60) will wakeup every 50ms or so to see if the condition has
> been fulfilled. If you do not specify a timeout, there will be no
> wakeups, but the main thread will also not listen (and react) to
> signals, such as sent by CTRL-C (or SIGTERM). So we would run danger of
> hanging indefinitely and not be able to react on Ctrl-C.
>

Even though that's true, I've found that's not the one who is actively
waiting.
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.

I don't understand why is this, because latest call to
threading.py/_Condition.wait() is done with a timeout=None, but still gets
busy on the following pasted lines of trace:

 --- modulename: threading, funcname: wait
threading.py(235):         print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ", timeout
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  None
threading.py(236):         if not self._is_owned():
 --- modulename: threading, funcname: _is_owned
threading.py(228):         if self.__lock.acquire(0):
threading.py(232):             return True
threading.py(238):         waiter = _allocate_lock()
threading.py(239):         waiter.acquire()
threading.py(240):         self.__waiters.append(waiter)
threading.py(241):         saved_state = self._release_save()
 --- modulename: threading, funcname: _release_save
threading.py(220):         self.__lock.release()           # No state to
save
threading.py(242):         try:    # restore state no matter what (e.g.,
KeyboardInterrupt)
threading.py(243):             if timeout is None:
threading.py(244):                 waiter.acquire()
threading.py(255):                 while True:
threading.py(256):                     gotit = waiter.acquire(0)
threading.py(257):                     if gotit:
threading.py(259):                     remaining = endtime - _time()
threading.py(260):                     if remaining <= 0:
threading.py(262):                     delay = min(delay * 2, remaining,
.05)
threading.py(263):                     _sleep(delay)

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.


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.

diff --git a/offlineimap/threadutil.py b/offlineimap/threadutil.py
index f69f8a6..1d1fb84 100644
--- a/offlineimap/threadutil.py
+++ b/offlineimap/threadutil.py
@@ -109,7 +109,7 @@ def exitnotifymonitorloop(callback):
             # we need a timeout in the get() call, so that ctrl-c can throw
             # a SIGINT (http://bugs.python.org/issue1360). A timeout with
empty
             # Queue will raise `Empty`.
-            thrd = exitthreads.get(True, 60)
+            thrd = exitthreads.get(True)
             # request to abort when callback returns true
             do_loop = (callback(thrd) != True)
         except Empty:



-- 
Álvaro Gámez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20150323/578dc961/attachment.html>