From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19047 invoked by alias); 24 Jul 2012 18:20:23 -0000 Received: (qmail 19036 invoked by uid 22791); 24 Jul 2012 18:20:20 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 24 Jul 2012 18:20:02 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q6OIK1Rp023947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jul 2012 14:20:01 -0400 Received: from [10.3.113.14] ([10.3.113.14]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q6OIK0mm031754; Tue, 24 Jul 2012 14:20:00 -0400 Message-ID: <500EE750.705@redhat.com> Date: Tue, 24 Jul 2012 18:20:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Jim Meyering CC: overseers@gcc.gnu.org Subject: Re: Multiple cvs/git mirror tasks? References: <50003CD7.8080401@redhat.com> <87bojjsm47.fsf@rho.meyering.net> <50045455.5090807@redhat.com> <87pq7q8kwp.fsf@rho.meyering.net> In-Reply-To: <87pq7q8kwp.fsf@rho.meyering.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org X-SW-Source: 2012-q3/txt/msg00037.txt.bz2 On 07/20/2012 12:19 PM, Jim Meyering wrote: > At first glance, you may think there are three invocations of the script, > but as recently discussed here, that's merely due to a subshelled > pipeline in the script: each element of the pipeline ends up looking > (in ps output) like another invocation of the parent script. It really > was invoked only once. Right, but in the ps output I sent before, there were two gdb runs (each with 3 processes) running at the same time. > I'm leery about adding naive cross-project locks, because that could > let a busy project starve one that needs only a tiny update. > > Using lockfile(1) and a timeout might help. > > I could add a per-project locking mechanism to prevent e.g., two gdb > syncs from running in parallel when the first one takes more than the > 30m between cron invocations. That could save some system resources, > but would not improve correctness or integrity. That makes sense to me. The times when it would run long are likely to correspond with times when system resources are tightest, as with the time I noticed. Jason