Active waiting?
Sebastian Spaeth
Sebastian at SSpaeth.de
Mon Mar 23 21:37:32 GMT 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://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20150323/2840c97a/attachment-0003.html>
More information about the OfflineIMAP-project
mailing list