Probably misunderstanding of the Threading/Lock code

X Ryl boite.pour.spam at gmail.com
Wed Sep 19 22:25:38 BST 2012


Hi all,

  While I was getting similar erroneous behaviour as reported in the list
previously, I've tried to track the issue in the code and found a major
issue.
In LocalStatus.py, LocalStatusSQLite.py,UIDMaps.py,
I'm seeing this pattern:

class LocalStatusFolder(BaseFolder):
    def __init__(self, name, repository):
    [...]
        self.savelock = threading.Lock()

    def save(self):
        with self.savelock:

I wonder the initial intend, but as I understand it, each INSTANCE of
the class will have its own lock/mutex, so the acquiring of the lock
in the method will only prevent mutual access if the same instance is
used in multiple thread.
That means that such code:
x1 = LocalStatusFolder(name, repo)
x2 = LocalStatusFolder(name, repo)
# In Thread 1
x1.save()
# In Thread 2
x2.save()

is not protected (it's racy).

I think the intend was to protect against all instance access to the
local status folder, that is, the "savelock" must be a static member
of the class.
In Python, it should be declared and used like this:

class LocalStatusFolder(BaseFolder):
    savelock = threading.Lock() # Notice it's out of the init method
    def __init__(self, name, repository):
    [...]
        self.savelock = threading.Lock()

    def save(self):
        with LocalStatusFolder.savelock: # Notice the use of the class
name and not self

I've not tracked where the instance of the LocalStatusFolder are used,
but you probably know better than me, but I think the corruption of
the local status folder reported by some user are caused by this.
The same applies the other files as well.

Best regards,
X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20120919/cbd50fc6/attachment-0002.html>


More information about the OfflineIMAP-project mailing list