Active waiting?

Sebastian Spaeth Sebastian at SSpaeth.de
Mon Mar 23 21:37:32 UTC 2015


Interesting, yep it could well be that the idle code also uses some timeouts while waiting for an event to happen.

I would suggest to let this be solved by a) a move to python3 b) an ugly hack like inserting a sleep as suggested by Nicolas or by c) using some elegant co-routine based solution that I am not capable to come up with (however I don't see a way how we could get rid of threads easily).

As I said, I gave up last time I looked into this.

Sebastian

Am 23. März 2015 18:06:26 MEZ, schrieb Alvaro Gamez <alvaro.gamez at hazent.com>:
>Hi again, I got some interesting new information
>
>2015-03-23 17:20 GMT+01:00 Alvaro Gamez <alvaro.gamez at hazent.com>:
>
>>  --- 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)
>>
>>
>After placing some more XXX and the like lines (as I told I'm not
>experiencied with python, I'm sure there's a better way to do this), it
>seems that I've triggered some optimizations out that provide me a more
>complete trace.
>
>threading.py(258):                     print "ZZZZZZZZZZZZZZZZZZZZZZZZZ
>",
>timeout
>ZZZZZZZZZZZZZZZZZZZZZZZZZ  1740
>
>That threading invocation with a timeout of 1740 matches the value of
>29minutes*60seconds of keepalive parameter.
>
>I've applied attached patch to allow a keepalive time of 0 seconds
>(which
>internally equates to an infinite wait) and now CPU consumption is 0
>and no
>wakeups are notified by powertop, so I think this is definitely the
>thing
>that is making offlineimap consume CPU while IDLING.
>
>Of course attached patch is not a solution, because that 29 minutes is
>a
>recommendation of the RFC for IDLE connections, so this is a timeout
>that
>should definitely exist, and the one to blame here is Event.wait().
>
>Best regards
>
>diff --git a/offlineimap/repository/IMAP.py
>b/offlineimap/repository/IMAP.py
>index 68c8e33..c2c279b 100644
>--- a/offlineimap/repository/IMAP.py
>+++ b/offlineimap/repository/IMAP.py
>@@ -72,7 +72,7 @@ class IMAPRepository(BaseRepository):
>         return self.getconfboolean("holdconnectionopen", 0)
>
>     def getkeepalive(self):
>-        num = self.getconfint("keepalive", 0)
>+        return self.getconfint("keepalive", 0)
>         if num == 0 and self.getidlefolders():
>             return 29*60
>         else:
>
>-- 
>Álvaro Gámez Machado
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OfflineIMAP-project mailing list:
>OfflineIMAP-project at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/offlineimap-project
>
>OfflineIMAP homepages:
>- https://github.com/OfflineIMAP
>- http://offlineimap.org

-- 
Sent from mobile phone. Please excuse brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20150323/2840c97a/attachment-0001.html>


More information about the OfflineIMAP-project mailing list