The only reason we used it here was to do a
traceback.print_exc(StringIO()) to get a string of our traceback. But we
can simply use traceback.format_exc() which exists since python 2.4.
One less module (and it is in the way to python 3 compatability too)
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Currently the Curses code is broken. Importing offlineimap.ui.Curses
will not succeed due to cyclic imports (threadutils imports ui, but ui
wants threadutils.MultiLock). So Curses cannot be chosen.
Incidentally, the only part in the code that uses "MultiLock" is the
Curses UI, to prevent concurrent access from several threads to the
ui-internal thread list and to IO resources such as the
screen. Fortunately for these purposes we don't need a MultiLock, so we
can do away with that implementation completely. A simple RLock that
allows us to have a thread "own" a lock and makes other threads wanting
access to the resource wait until the owning thread is finished.
The MultiLock implementation looked a bit weird, so simplifying code
here is a good thing, it might well be that we fix some "hangs" that
have been reported (and that would only ever occur with the Curses UI).
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
The latter is shorter and looks nicer. UIBase was a very weird class
name for something that is "user visible". We don't need to use (or
see) it from higher level code for most of the code now.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
the cProfile/profile modules are great for performance debugging. The
pure-python profile module has much more overhead though and the
cProfile module is recommended if it exists. This changes to import to
first try the cProfile module and then fall back to the profile
module. The cProfile/profiles modules are API compatible for all that
its worth...
If that does not exist we continue to complain as before.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
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@SSpaeth.de>
Signed-off-by: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
From Jim Pryor
The first, "cleanup.patch", cleans up a few spots that tend to throw
exceptions for me as offlineimap is exiting from a KeyboardInterrupt.
module threading should be taken out back and shot.
Condition.wait() is a busywait loop that has negative implications for
battery consumption on laptops.
Queue.get() in blocking mode blocks SIGINT from being delivered.
Argh, argh, argh.
Closes: #493801.
