Merge lp:~jml/lazr.restfulclient/multiple-instance-safe into lp:lazr.restfulclient
Status: | Merged |
---|---|
Approved by: | j.c.sackett |
Approved revision: | 141 |
Merged at revision: | 122 |
Proposed branch: | lp:~jml/lazr.restfulclient/multiple-instance-safe |
Merge into: | lp:lazr.restfulclient |
Diff against target: |
319 lines (+260/-6) 3 files modified
buildout.cfg (+1/-0) src/lazr/restfulclient/_browser.py (+101/-6) src/lazr/restfulclient/tests/test_atomicfilecache.py (+158/-0) |
To merge this branch: | bzr merge lp:~jml/lazr.restfulclient/multiple-instance-safe |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
j.c.sackett (community) | Approve | ||
Richard Harding | code* | Approve | |
Review via email: mp+98873@code.launchpad.net |
Commit message
Creates AtomicFileCache as a parent class for MultipleReprese
Description of the change
Hello,
I now work on a couple of projects that carry workarounds for bug 459418. It's not economical for my employer to be constantly maintaining these workarounds and to keep hitting this bug when writing new code that uses launchpadlib. As such, I offer this patch to make the file cache used by lazr.restfulclient safely shareable by multiple processes/threads.
It's an adaptation of the patch at http://
It adds a new class, AtomicFileCache, and makes the MultipleReprese
Essentially, there are two components:
1. Change look-before-
2. Do an atomic write in set, relying on the filesystem's atomic rename feature. This is not actually atomic on Windows, but will not be any buggier for them than the current code.
If you are interested in the subject of atomic writes, you might like to read <http://
There are no tests. It's really hard to produce reliable tests for the race conditions that you find here without substantially changing the public API of the file cache. httplib2 doesn't have any tests for the interface of FileCache, otherwise I would have tried to re-use those. It wouldn't be too draconian to insist on adding some basic interface tests (e.g. does get() get what set() sets?) here, I think.
I look forward to hearing from you.
jml
Thanks for this.