<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 10:16 PM Martin Doucha <<a href="mailto:mdoucha@suse.cz" target="_blank">mdoucha@suse.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/8/20 7:35 AM, Li Wang wrote:<br>
> 1. We need to update the doc/test-writing-guidelines.txt too.<br>
<br>
Right. I'll resubmit in a moment.<br>
<br>
> 2. Maybe better to let the shell version is consistent with this new?<br>
<br>
That doesn't make much sense. Shell programs and functions have much<br>
simpler call conventions than C functions. If you really need to test a<br>
more complex result than a single return value in shell, writing a<br>
wrapper function is much easier than writing a validator function.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">According to the default convention of LTP, we maintain two versions of LTP APIs(C and Shell), we always keep them consistent for creating unified tests.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But here I'm OK to reserve a difference for the TST_RETRY_FUNC macro because it looks a bit complicated to achieve the same one in shell. If anyone has different thought please let me know :).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In C, it's the other way around. Writing a wrapper function would often<br>
be a ton of work compared to writing a simple retval validator macro.<br>
<br>
> 3. I remember there were discussions to support enabling infinite loop<br>
> in TST_RETRY_FUNC, but not sure if it is possible to add in this patch,<br>
> or we can do that after your patch merged.<br>
> <a href="http://lists.linux.it/pipermail/ltp/2019-October/013896.html" rel="noreferrer" target="_blank">http://lists.linux.it/pipermail/ltp/2019-October/013896.html</a><br>
<br>
I'll leave that to someone else. Though I'd say that timeout of<br>
(1ULL<<40) should be infinite enough for everybody. All we need to do is<br>
change tst_delay_ and tst_max_delay_ type to unsigned long long.<br></blockquote><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Right. It seems no special need to achieve the infinite loop so far.</div><div class="gmail_default" style="font-size:small"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>     ...<br>
>             sprintf(defunct_tid_path, "/proc/%d/task/%d", getpid(),<br>
>     defunct_tid);<br>
>     -       TST_RETRY_FN_EXP_BACKOFF(access(defunct_tid_path, R_OK), -1,<br>
>     15);<br>
>     +       ret = TST_RETRY_FN_EXP_BACKOFF(access(defunct_tid_path, R_OK),<br>
>     +               CHECK_ENOENT, 15);<br>
> <br>
> <br>
> The test total timeout is set to 20 seconds, here reserve 15 seconds is<br>
> too much for the macro looping because doing exponential backoff in<br>
> 15secs(1us+2us+4us+..) actually larger than the 20secs. So I suggest<br>
> raising the tst_test.timeout at the same time or set a smaller value to<br>
> MAX_DELAY.<br>
<br>
Actually, this entire retry loop will never take longer than 17 seconds.<br>
The last single delay will be at most 8.4 seconds (2^23 microseconds)<br>
long and the total combined delay before that will also take 8.4<br>
seconds. The next delay would be 16.8 seconds which is too much so the<br>
loop will end. The main test function takes only a few milliseconds so<br>
there's no problem even in the worst case scenario.<br>
<br>
I can change the delay to 9 seconds if you want. It'll make no<br>
difference in practice but the code will be less confusing to humans.<br>
<br>
-- <br>
Martin Doucha   <a href="mailto:mdoucha@suse.cz" target="_blank">mdoucha@suse.cz</a><br>
QA Engineer for Software Maintenance<br>
SUSE LINUX, s.r.o.<br>
CORSO IIa<br>
Krizikova 148/34<br>
186 00 Prague 8<br>
Czech Republic<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Regards,<br></div><div>Li Wang<br></div></div></div></div>