This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] testsuite: pthread_cond_wait.exp: Avoid a race
On Tue, 12 Feb 2013 18:23:01 +0100, Joel Brobecker wrote:
> > It is just too racy. I will check in the easy workaround below, it is
> > sure not a real fix.
>
> 2 seconds feels much much much too long, however.
2 seconds is a general delay standard in the testsuite so I do not find it
would hurt so much:
$ grep 'sleep 2' */*.exp|wc -l
20
> I try to avoid
> these types of delays, because collectively they make a significant
> dent on the overall amount of time it takes to run the testsuite.
The testsuite is already directory-parallelized and soon Tom should introduce
even a file-parallelization, so sleep should not hurt much.
> I am trying to think of a way to rewrite the program to avoid
> the delay entirely,
Yes, I understand the sleep is terribly but as it is so widespread in the
testsuite I just found it a "good enough" fix. Sure I can keep it only among
my local non-upstreamed testsuite races fixes so that I can continue running
the daily regression testing:
gdbserverasyncnonstop.patch
watchpointfork2.patch
gccpr4.patch
valgrind-kill.patch
> but I don't think it's possible,
IMO there should be retrying. If it does not find the symbol then resume it
for another 0.1 sec or even 1 sec as such case does not commonly happen.
> Can we try a smaller value?
No. IMO even those 2 seconds is too long. The machine has load about 20-30
when running the parallelized testsuites (I always run 3 at once) and I would
like to parallelize it even more if the testsuite already was not so fragily
gainst even higher loads.
Thanks,
Jan