From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3919 invoked by alias); 9 Jan 2008 12:55:59 -0000 Received: (qmail 3910 invoked by uid 22791); 9 Jan 2008 12:55:58 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Jan 2008 12:55:37 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id E441A17F554 for ; Wed, 9 Jan 2008 10:49:55 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m09CtXj44218988 for ; Wed, 9 Jan 2008 10:55:34 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m09CtX2a023422 for ; Wed, 9 Jan 2008 10:55:33 -0200 Received: from [9.18.238.70] (gargoyle.br.ibm.com [9.18.238.70]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m09CtX4f023416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2008 10:55:33 -0200 Subject: Re: [patch] Fix watch_thread_num testcase for ppc32 From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Daniel Jacobowitz Cc: Joel Brobecker , gdb-patches@sourceware.org In-Reply-To: <20080109124806.GC27746@caradoc.them.org> References: <1199849652.22083.20.camel@gargoyle> <20080109041508.GA21281@adacore.com> <1199871500.22083.29.camel@gargoyle> <20080109124806.GC27746@caradoc.them.org> Content-Type: text/plain Date: Wed, 09 Jan 2008 12:55:00 -0000 Message-Id: <1199883329.11932.13.camel@gargoyle.br.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit 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: 2008-01/txt/msg00184.txt.bz2 > Five threads looping without a CPU delay really messes up interactive > performance; that's why I reduced the thread count for schedlock.exp > recently. Sounds like a good reason to leave the delay there. > Sounds to me like a bug in GDB, not a problem with the test. Yes, probably. I believe there is a signal being missed somewhere. If i use usleep(0) (calls sched_yield), the testcase runs just fine. But switching to a delay eventually breaks the test. Any ideas? -- Luis Machado Software Engineer IBM Linux Technology Center