Singlethreading patch series

[Nicolas Sebrecht]

On Wed, Jan 12, 2011 at 10:50:49AM +0100, Sebastian Spaeth wrote:

> OK, this is my proposal of how to proceed. I will post my updated patch
> series as a response to this email in a second. It consists of:
> 0001-Catch-SystemExit-and-KeyboardInterrupt-exceptions.patch
> 0002-Catch-KeyboardInterrupt-exceptions-explicitely.patch
> 0003-LocalStatus-Don-t-ignore-Exceptions-on-os.fsync.patch
> 0004-Clean-up-import-s.patch
> 0005-Implement-true-single-threading.patch
> 0006-Imply-single-threaded-mode-whith-d-ebug-command-line.patch
> 
> In response to Johannes and your comments, I see the following options:
> 
> a) Merge patches 1-6. They allow us to run everything in a single thread
>    and allow us to ctrl-c abort the run. A separate topic should be
>    created once this is merged that does away with the catch-it all
>    exceptions. We will likely need to examine each case carefully to see
>    which exceptions can occur and which are "expected" respectively in
>    which cases we can give clear error messages to the user.
> 
> b) Merge patches 1-2,4-6. Similar to the last option, but patch 3
>    already belongs to the new patch series examining our cases of
>    catch-it-all. So skip patch 3 in *this* topic and save it for the
>    next.
> 
> c) Merge patches 4-6. Don't touch the exception handling at all and
>   leave all those changes to the future topic. This has the disadvantage
>   that ctrl-c in single-threaded mode does nothing yet but abort
>   e.g. the current folder sync (only to continue with the next
>   mail/folder/account), so aborting the run is not easily possible in
>   this state.

What about (d) ?

d) Like (a) but change patch 3 to do away the "catch-it all exceptions"
and only catch already known exceptions?

This way we would have users work with us (by reporting issues) in a
_real_ use case manner. Or do you plan (...if it were possible) to go
through all the underlying code and library to check what is raised and
when?

Or do you have a better strategy in mind?

> > The last change would be to make the Singlethreading option the default
> > in debug mode (if not already done).
> 
> Done, this makes sense. With the slight complication that we can also
> invoke "-d thread" which is supposed to do thread debugging. (but was/is
> still broken in python 2.6). So patch 6/6 of the new series implies
> single-threading UNLESS we include "thread" as a debug option. (In this
> case one can still manually select the -1 option from command line)

Smart.

As a side note I would ask you to add a brief inter-diff summary in your
introduction mail and the inter-diff (attached or following) from the
previous topic release. This makes the review code much easier on (big
enough) topics.

Thanks,

-- 
Nicolas Sebrecht