CFT: fix OfflineIMAP lockup in single-threaded mode

[Nicolas Sebrecht]

On Tue, Jan 29, 2013 at 10:17:12AM +0400, Eygene Ryabinkin wrote:
> Mon, Jan 28, 2013 at 09:39:46PM +0100, Nicolas Sebrecht wrote:

> > 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.

What's the problem? Basically, we have one configuration file and one
dedicated python object instanciated. Everything should be fine as the
configuration is already written and everywhere else in the code we only
need to read it. You could add a comment to the CustomConfigParser
object if you think it worth.

> > 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.

Thanks for sharing it. May I ask what real problem are you trying so
solve? Concurrent access to the config variable only?

-- 
Nicolas Sebrecht