From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23925 invoked by alias); 6 Jan 2003 00:49:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23911 invoked from network); 6 Jan 2003 00:49:36 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 6 Jan 2003 00:49:36 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h060nOh25125; Sun, 5 Jan 2003 18:49:24 -0600 Date: Mon, 06 Jan 2003 00:49:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200301060049.h060nOh25125@duracef.shout.net> To: bje@redhat.com, gdb-patches@sources.redhat.com Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) Cc: binutils@sources.redhat.com, gcc-patches@gcc.gnu.org X-SW-Source: 2003-01/txt/msg00194.txt.bz2 Ben Elliston writes: > If, instead, the cache were a "dot" directory that contained files > whose filenames had the form "key=value", then test results could be > examined or updated using atomic file system operations and there > should be no races. The Linux kernel does something similar for its configuration variables (which are different than autoconf cache entries): one file per variable. The kernel does this to achieve fine-grained dependencies on the configuration, so that changing CONFIG_DRIVER_FOO causes recompilation of only the files that depend on CONFIG_DRIVER_FOO. With a little care I think this would be thread safe. One tricky point is that you have to be prepared for a file to not exist at the moment you open it because some other thread is doing an "unlink / rename" at that moment. Since this is a cache, that will simply cause some extra cache misses. There is a potential for a thundering-herd performance problem where every thread wants to compute HAVE_FOO_H, they all deposit identical copies into the cache, and then they move on and see that HAVE_BAR_H is not in the cache either, lockstepping their way through similar configure scripts. It would actually improve efficiency for autoconf to randomize the order of tests in the configure script. :) Also, I think that you could mix the two cache styles in a single tree. All the old-style subdirectories would use config.cache, and all the new-style subdirectories would use the new fine-grained cache. Serialization would be needed only for old-style "config.cache" subdirectories. New-style subdirectories could somehow say to autogen "I am new-style, I use the new fine-grained cache, don't serialize my configure goal with other configure goals." There would be a performance penalty for a mixed tree, which would go away when the last old-style subdirectory got upgraded. Michael C back-seat driver :)