From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9652 invoked by alias); 5 May 2011 18:57:24 -0000 Received: (qmail 9643 invoked by uid 22791); 5 May 2011 18:57:24 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 18:57:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 1E5A22BB298; Thu, 5 May 2011 14:57:08 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WecQgS7xpZb2; Thu, 5 May 2011 14:57:08 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1C3022BB297; Thu, 5 May 2011 14:57:07 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 38EFC145615; Thu, 5 May 2011 11:57:05 -0700 (PDT) Date: Thu, 05 May 2011 18:57:00 -0000 From: Joel Brobecker To: Janis Johnson Cc: Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [RFA] bailing out of tests with multiple errors or timeouts Message-ID: <20110505185705.GA2568@adacore.com> References: <4DC1910A.8040603@codesourcery.com> <201105041810.p44IAVlq008135@glazunov.sibelius.xs4all.nl> <4DC2C957.2070307@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC2C957.2070307@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2011-05/txt/msg00156.txt.bz2 There was a discussion in the past about this, and we thought that the benefit of continuing after detecting a TIMEOUT was, overall, usually nul. A timeout is often a source of loss of synchronization between what you're sending and the associated output, so continuing in that situation isn't going to be all that useful. I'm sure we'll find some counter examples, but the ration between benefits vs time wasted is probably going to remain very small. So the conclusion the two of us who discussed this reached was that we should just abort the testcase at the first TIMEOUT. But rather than do it in an ad hoc way as is done here, do it systematically. The problem is, I haven't found a way to do this, yet. I thought about raising an exception, but I don't think there is a way for the testsuite to trap it before dejagnu sees it... -- Joel