I'm attaching a patch that applies on top of this.
That I can remember, you only needed to reduce the wait interval, not
to make it ever larger, so I'm simplifying this so -W only takes
microseconds.
I have only included some missing error check in case -W is specified
but -w is not.
I can
Compilation breaks with this patch:
xtables.c: In function ‘do_parse’:
xtables.c:1029:8: error: ‘restore’ undeclared (first use in this
function)
if (restore) {
^
xtables.c:1029:8: note: each undeclared identifier is reported only
once for each function it appears in
On 2016-05-17 12:25, subas...@codeaurora.org wrote:
iptables -w 2.1
0.01s sleep, retry
0.02s sleep, retry
0.03s sleep, retry
...
2.1s sleep, exit
Note that it sleeps for 10ms and retries rather than sleeping for a
single
iteration for 2.1s seconds and then retrying.
Let me know if there are
iptables -w 2.1
0.01s sleep, retry
0.02s sleep, retry
0.03s sleep, retry
...
2.1s sleep, exit
Note that it sleeps for 10ms and retries rather than sleeping for a
single
iteration for 2.1s seconds and then retrying.
Let me know if there are any concerns with this.
But this is changing the
My impression after looking at this patch is that you can simplify it
using 'struct timeval' and use select() to wait for the time you need.
Hi Pablo
Sure, I can send a v3 with the select. Just to clarify, here is what the
patch does -
iptables -w 2.1
0.01s sleep, retry
0.02s sleep,
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
