You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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?
The text was updated successfully, but these errors were encountered: