Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 35620 invoked from network); 4 Aug 2007 00:11:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Aug 2007 00:11:36 -0000 Received: (qmail 81142 invoked by uid 500); 4 Aug 2007 00:11:36 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 81127 invoked by uid 500); 4 Aug 2007 00:11:36 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 81115 invoked by uid 99); 4 Aug 2007 00:11:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Aug 2007 17:11:36 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Aug 2007 00:11:15 +0000 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l740B9s6015306 for ; Sat, 4 Aug 2007 00:11:09 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Aug 2007 18:10:07 -0600 Message-ID: <46B3C438.5060003@roguewave.com> Date: Fri, 03 Aug 2007 18:11:36 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: num_get thread safety tests References: <46B34AC8.3060504@roguewave.com> <46B36EB6.9040308@roguewave.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Aug 2007 00:10:07.0666 (UTC) FILETIME=[D0B2B920:01C7D62B] X-Virus-Checked: Checked by ClamAV on apache.org Travis Vitek wrote: > > >> Martin Sebor wrote: >> >> I suppose that would be okay just so long as it's possible to still >> exercise one facet without the other. Which I suspect might defeat >> your goal of integrating the testing of both facets into the same >> program. >> >> The problem with creating a dependency between the two facets is >> that a bug in one might prevent the other from ever being tested >> or might cause false positives in the other, making debugging the >> problem more difficult. At the same time, exercising both of the >> facets simultaneously would be valuable in its own right so it >> would be nice to be able to do both. > > Okay, I think I'm going to settle for having separate tests for the get > and put. I believe this is what you had originally intended, and I hope > that is still acceptable. It's definitely the easier of the two approaches and I agree it's the way to go if you don't want to get bogged down in fixing the process API in the test driver. We will need to fix it at some point but now is not the time. > >> An idea that would let us have it both ways is to integrate the >> tests for both (all three when you count numpunct) facets into >> the same program, still keeping the option of running them >> independently of one another, exercising them all at the same >> time by default and, when one fails, invoking the program again >> and exercising them independently, one after another. This >> approach would involve at least two processes: one to drive and >> monitor the tests, and another one or more running the tests >> themselves. The infrastructure for this approach has already been >> put in place: see the rw_process_create() API in the test driver. >> Unfortunately, the tests for the API have been failing on a number >> of platforms so there are issues with it that remain to be resolved. > > That is more trouble than I'm wanting to chew on at this time. This > seems rather complicated, and since I'm not yet familiar with how the > testing infrastructure works, I'm worried that I would end up spending > time trying to get this approach to work and not writing tests. Agreed. Martin