CFT: fix OfflineIMAP lockup in single-threaded mode

[Eygene Ryabinkin]

Mon, Jan 28, 2013 at 09:39:46PM +0100, Nicolas Sebrecht wrote:
> On Mon, Jan 28, 2013 at 10:47:22PM +0400, Eygene Ryabinkin wrote:
> > If we will make, say, 'options' to the global variable, some code can
> > unintentionally modify it and this will be very hard to trace, since
> > any piece of code can do it: variable is global.
> 
> How some code would modify the global variable 'options'?

It can do it within the same file by using "global" keyword, but
you're right: it won't work across multiple source files.  My long C
background sometimes plays a bad role :((

Though, making 'options' global by using the special module for it, like
{{{ offlineimap/globals.py
options = None
}}}
and referencing it as offlineimap.globals.options will make everyone
to be able to modify it again.  More on this below.

> Might be just a matter of opinions but python expects developpers to
> know what they do (e.g. attributes of objects are public). Does
> safety justify the resulting complexity of the code? Not sure.

Well, we should have some means to pass at least parts of the options
from offlineimap/init.py to the underlying code.  I see the following
ways:

 - passing it explicitely; this will require the changes in all places
   of code that want to receive the options; this is the most explicit
   way of doing this, but it costs some code rewriting every time one
   wants to pass all or some options to the new code;

 - make options to be globally-accessible; that can be done in many
   ways,

   * the simplest is to have some module-global variable that can
     be accessed from the outside.  But not very carefully thought
     changes of is or its contents can lead to (not so) funny results.

   * my way has more code due to two things: singleton implementation
     and protection from accidential attempts of double-instantiation.

And I understand that developers should know what they do, but it
holds only in the "Best of the worlds (TM)", in our reality there
should be some protections and the real question is "Are there
protections and added complexity in one place outweight the problems
that may arise of the modifications that can easily be made if these
protections aren't there".  And as at least options.singlethreading
has crucial meaning for internals of OfflineIMAP (or locks will
arise), I had tried to design the things in a protective way.

Again, I should reiterate all this once more within myself, because
when people are voting against some changes, this usually means
that there could be a better way to do it, but my current reasoning
is outlined above.
-- 
rea