This break the "-w" option's semantic, i.e. if the user input
"iptables -w 1", and concurrency happen,
we will just only wait 10ms and return an error.
If there's any chance this patch can break existing setups then we
can't take this.
I'd suggest you add support to express millisecond precisi
On Thu, Apr 28, 2016 at 09:37:32AM +0800, Liping Zhang wrote:
> 2016-04-08 11:07 GMT+08:00 Subash Abhinov Kasiviswanathan
> :
> > @@ -257,10 +258,15 @@ bool xtables_lock(int wait)
> > return true;
> > else if (wait >= 0 && waited >= wait)
> >
2016-04-08 11:07 GMT+08:00 Subash Abhinov Kasiviswanathan
:
> ip[6]tables currently waits for 1 second for the xtables lock to
> be freed if the -w option is used. We have seen that the lock is
> held much less than that resulting in unnecessary delay when
> trying to acquire the lock. This problem
ip[6]tables currently waits for 1 second for the xtables lock to
be freed if the -w option is used. We have seen that the lock is
held much less than that resulting in unnecessary delay when
trying to acquire the lock. This problem is even severe in case
of latency sensitive applications.
Introduc
