Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tryLock() should return an error if it fails to acquire a lock #64

Open
yannh opened this issue Jul 14, 2019 · 0 comments
Open

tryLock() should return an error if it fails to acquire a lock #64

yannh opened this issue Jul 14, 2019 · 0 comments

Comments

@yannh
Copy link
Contributor

yannh commented Jul 14, 2019

The documentation of tryLock states that "if the exclusive lock would block (i.e. because another process already holds it), no error is returned". This seems counter-intuitive - if tryLock fails to acquire a lock, shouldn't it return an error, so that the calling function could retry?

Here: https://github.com/coreos/go-iptables/blob/master/iptables/iptables.go#L438 if the file was locked and we failed to acquire a lock, we would still try to run iptables, which might lead to errors. What would you think of returning an error in tryLock if it fails to acquire the lock, and looping over tryLock (at least a few times) here https://github.com/coreos/go-iptables/blob/master/iptables/iptables.go#L438 in case a EWOULDBLOCK error is returned, until it can acquire the lock?

Note: the behaviour of iptables is actually to sleep 1s and try to acquire the lock again: https://git.netfilter.org/iptables/tree/iptables/xshared.c?h=v1.6.0#n260 would you accept a patch to mimic this behaviour?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant