CFT: fix OfflineIMAP lockup in single-threaded mode

Eygene Ryabinkin rea at
Wed Jan 30 06:30:53 GMT 2013

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

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

More information about the OfflineIMAP-project mailing list