On 10/10/15 9:54 PM, Mike Frysinger wrote:
We create self.snapcache_lock to hold the lock, then assign it to self.snapshot_lock_object, and then operate on self.snapshot_lock_object. There's no need for this indirection, so operate on self.snapcache_lock directly instead. --- catalyst/base/stagebase.py | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
This and the next patch look fine and simplify matters a lot. This doesn't fix bug #519656 but it clears the way. When running multiple instances of catalyst, if the second instance tries to acquire the lock on the snapcache while the first one has it, it throws and exception instead of waiting on the lock. It would be nice for it to wait and timeout if it doesn't get the lock within some acceptable time limit.
On systems with lots-o-cores I run mutliple instances of catalyst to economize on throughput.
-- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : [email protected] GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
