[patch] testsuite: pthread_cond_wait.exp: Avoid a race

Jan Kratochvil jan.kratochvil@redhat.com
Tue Feb 12 17:30:00 GMT 2013


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



More information about the Gdb-patches mailing list