From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24540 invoked by alias); 12 Feb 2013 17:30:10 -0000 Received: (qmail 24527 invoked by uid 22791); 12 Feb 2013 17:30:09 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Feb 2013 17:29:58 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1CHTtrq017774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 12:29:56 -0500 Received: from host2.jankratochvil.net (ovpn-116-18.ams2.redhat.com [10.36.116.18]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1CHTo46003743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 12 Feb 2013 12:29:53 -0500 Date: Tue, 12 Feb 2013 17:30:00 -0000 From: Jan Kratochvil To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [patch] testsuite: pthread_cond_wait.exp: Avoid a race Message-ID: <20130212172950.GA6877@host2.jankratochvil.net> References: <20130212170358.GA5633@host2.jankratochvil.net> <20130212172301.GH17107@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130212172301.GH17107@adacore.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00280.txt.bz2 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