CFT: fix OfflineIMAP lockup in single-threaded mode

[Eygene Ryabinkin]

Tue, Jan 29, 2013 at 05:45:50PM +0100, Nicolas Sebrecht wrote:
> 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.

Hmm, I was talking about the 'options' that is produced by optparse's
OptionParser.

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

Modification of the 'options' object by code that lives outside the
offlineimap/init.py, but having a way to provide the global access
to the 'options' without the need to pass it explicitely through
the calls or instantiations.

Though OK, seems like this variant is a no-go, because there are too
much cons and objections raised, so I'll craft the other one, that
will most likely use global 'options' and fully-constifying approach
for that: anything that needs read-only access to the 'options' will
have it through the global object and if someone needs write access,
then the real 'options' should be passed there.
-- 
rea