ionelmc / python-redis-lock

Lock context manager implemented via redis SET NX EX and BLPOP.
https://pypi.python.org/pypi/python-redis-lock
BSD 2-Clause "Simplified" License
550 stars 78 forks source link

Inconsisten usage of `_held` #48

Closed AndreiPashkin closed 5 years ago

AndreiPashkin commented 8 years ago

1) Here and here - duplicate check for case if a lock is already held - additional overhead. 2) Here - _held is not used, and if not - what is the point of it's existence? 3) Here - it is kind of duplicate, since nx=True is already ensures, that a lock will not override already held lock. And also it produces additional overhead, making additional call to Redis.

So _held produces additional calls to Redis in case of redundant checks or usage of _held, because _held calls to Redis. And it's just violates Feng Shui rules.

ionelmc commented 8 years ago

1) Here and here - duplicate check for case if a lock is already held.

Indeed. Will remove that.

2) Here - _held is not used, and if not - what is the point of it's existence?

So basically it's just used in acquire. Are you proposing to use a script in acquire?

AndreiPashkin commented 8 years ago

So basically it's just used in acquire. Are you proposing to use a script in acquire?

If remove _held call, acquire still won't override already held locks, because of nx=True, so call to _held is partially redundant. Partially - becasue nx=True doesn't perform matching by id's.

ionelmc commented 8 years ago

Yes but it won't raise proper exception either.

AndreiPashkin commented 8 years ago

Yes, but should it?

ionelmc commented 8 years ago

Yes, if user makes something bad then error should be raised instead of treating the problem silently.

AndreiPashkin commented 8 years ago

Another proposition is to make _held public.

AndreiPashkin commented 8 years ago

Yes, if user makes something bad then error should be raised instead of treating the problem silently.

Makes sense.

ionelmc commented 8 years ago

Another proposition is to make _held public.

Hmmm. threading.Lock has a method locked. I think we can match that.

AndreiPashkin commented 8 years ago

Yes, if user makes something bad then error should be raised instead of treating the problem silently.

By the way - currently - this check is performed only in the beginning, but not in blocked state. Should it throw the error in blocked state?

ionelmc commented 8 years ago

Good point. I have to investigate.

ionelmc commented 5 years ago

Uh ... well kinda late but: in acquire there is this check:


        if self._held:
            raise AlreadyAcquired("Already acquired from this Lock instance.")

So I think all problems are resolved?