From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:19:53 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A6416A403; Fri, 29 Sep 2006 14:19:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C05A43D95; Fri, 29 Sep 2006 14:19:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E416046D33; Fri, 29 Sep 2006 10:19:50 -0400 (EDT) Date: Fri, 29 Sep 2006 15:19:50 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20060929140802.GH4776@rambler-co.ru> Message-ID: <20060929151750.Y74256@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <20060929140802.GH4776@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 14:19:54 -0000 On Fri, 29 Sep 2006, Ruslan Ermilov wrote: >>> I don't know of a better fix. Another approach is that mentioned in the >>> commit log and used by NetBSD. I tried it, and it was very fragile -- it >>> could easily leave the temporary file around, and that would stuck forever >>> another instances. >>> >>> The problem at hand is that multiple instances of install-info(1) are >>> attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have >>> a better idea, don't hesitate to let me know. I'd very much like to get >>> rid of that as well. >> >> The basic problem here is that install-info doesn't support parallelism. >> Sounds like we just need to accept that and therefore accept that we don't >> support doing installworld with the -j argument. A middle-ground solution >> would be to only use lockf if -j is used. >> > How could it support parallelism without using lockf(3) or equivalent? I'd > be happy to hack install-info(1) if there's a way. Yes, that's why it's the basic problem. :-) The problem is the way info works -- that it uses a shared file for a global table of contents, rather than constructing it from a set of independent files once. Is there any way to generate the entries in the directory incrementally in different files, then combine them all at the end once? I.e., like we do with the man page apropos database -- we build all the elements independently, which is parallelizable, and then once at the end once it's all done, we build the single central database. > A middle-ground solution was easy to implement, and I have a patch for it if > a more clean solution couldn't be found. I'd like to see that in the tree in the near future. If nothing else, it will speed up installworld in the non-j case, probably measurably (although I've not measured it :-). Robert N M Watson Computer Laboratory University of Cambridge