[PATCHv3] Don't always sleep while waiting for exited threads

[Leif Walsh]

You should probably do the code changes and doc changes in separate commits
so they can be reverted separately. Generally, changes that do not depend on
each other to work correctly should be separated for this reason. You should
note the change to the code in the docs (in the same commit) then do the
change to sphinx style in another commit.
On Dec 4, 2010 4:44 PM, "Sebastian Spaeth" <Sebastian at sspaeth.de> wrote:
> Rather than poll our exitthread Queue in a non-blocking fashion and
> always sleep for 1 second inbetween, simply call it in a blocking
> fashion which will return immediately when a thread has exited. This
> is somewhat faster as we don't do unnecessary sleeps after a thread
> exited.
>
> Do note that we need to specify some timeout value here (the 60 chosen
> is pretty arbitary, but what the value exactly is, is not that
> important, it could be any positive value) in order to make the
> Queue.get() call work with SIGINT (cf
> http://bugs.python.org/issue1360).
>
> Signed-off-by: Sebastian Spaeth <Sebastian at SSpaeth.de>
> ---
> Reworded the commit message, I've kept the documentation style for now. If
sphinx autogenerated-docs is not what people what, I can revert to plain old
docs.
>
> offlineimap/threadutil.py | 31 ++++++++++++++++++++-----------
> 1 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/offlineimap/threadutil.py b/offlineimap/threadutil.py
> index c65700e..da7bcf6 100644
> --- a/offlineimap/threadutil.py
> +++ b/offlineimap/threadutil.py
> @@ -101,22 +101,31 @@ def initexitnotify():
> pass
>
> def exitnotifymonitorloop(callback):
> - """Enter an infinite "monitoring" loop. The argument, callback,
> - defines the function to call when an ExitNotifyThread has terminated.
> - That function is called with a single argument -- the ExitNotifyThread
> - that has terminated. The monitor will not continue to monitor for
> - other threads until the function returns, so if it intends to perform
> - long calculations, it should start a new thread itself -- but NOT
> - an ExitNotifyThread, or else an infinite loop may result. Furthermore,
> - the monitor will hold the lock all the while the other thread is
waiting.
> + """An infinite "monitoring" loop watching for finished
ExitNotifyThread's.
> +
> + :param callback: the function to call when a thread terminated. That
> + function is called with a single argument -- the
> + ExitNotifyThread that has terminated. The monitor will
> + not continue to monitor for other threads until
> + 'callback' returns, so if it intends to perform long
> + calculations, it should start a new thread itself -- but
> + NOT an ExitNotifyThread, or else an infinite loop
> + may result.
> + Furthermore, the monitor will hold the lock all the
> + while the other thread is waiting.
> + :type callback: a callable function
> """
> global exitthreads
> - while 1: # Loop forever.
> + while 1:
> + # Loop forever and call 'callback' for each thread that exited
> try:
> - thrd = exitthreads.get(False)
> + # 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)
> callback(thrd)
> except Empty:
> - time.sleep(1)
> + pass
>
> def threadexited(thread):
> """Called when a thread exits."""
> --
> 1.7.1
>
>
> _______________________________________________
> OfflineIMAP-project mailing list
> OfflineIMAP-project at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/offlineimap-project
>
> OfflineIMAP homepage: http://software.complete.org/offlineimap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/offlineimap-project/attachments/20101204/adf49aad/attachment.htm>