From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10911 invoked by alias); 23 Dec 2002 21:28:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10892 invoked from network); 23 Dec 2002 21:28:47 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 23 Dec 2002 21:28:47 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBNLSYY17717; Mon, 23 Dec 2002 16:28:34 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6) with ESMTP id gBNLSXh9008008; Mon, 23 Dec 2002 19:28:33 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id gBNLSXiY008000; Mon, 23 Dec 2002 19:28:33 -0200 To: DJ Delorie Cc: drow@mvista.com, gcc@gcc.gnu.org, neroden@gcc.gnu.org Subject: Re: Serialization dependencies muck up configure-on-demand References: <20021223182335.GA17240@nevyn.them.org> <200212231833.gBNIX4o14365@greed.delorie.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Mon, 23 Dec 2002 14:37:00 -0000 In-Reply-To: <200212231833.gBNIX4o14365@greed.delorie.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg01376.txt.bz2 On Dec 23, 2002, DJ Delorie wrote: >> Do we need the serialization dependencies? > We need to make sure that no two configures run at the same time. If > you can figure out a better way to do that, please do. We can use shell locking (*) in the top level to make sure no two configures run at the same time, if we really need that. Serialized dependencies are exactly the wrong way to solve the problem, IMO. I hadn't realized they had been implemented like that, otherwise I'd have objected. (*) attempt to create a directory say configure.lock and sleep until creation succeeds, then run sub-configure, then rmdir it. This can fail in the rare advent of the build directory being on an unreliable NFS server, such that the reply of mkdir fails to get to the client, that retries the operation and then gets a failure because the directory now exists. We can probably live with that. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer