Closed AndreiPashkin closed 5 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?
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.
Yes but it won't raise proper exception either.
Yes, but should it?
Yes, if user makes something bad then error should be raised instead of treating the problem silently.
Another proposition is to make _held
public.
Yes, if user makes something bad then error should be raised instead of treating the problem silently.
Makes sense.
Another proposition is to make _held public.
Hmmm. threading.Lock
has a method locked
. I think we can match that.
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?
Good point. I have to investigate.
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?
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, sincenx=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.