From owner-freebsd-hackers Fri Feb 10 17:21:14 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id RAA17980 for hackers-outgoing; Fri, 10 Feb 1995 17:21:14 -0800 Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id RAA17970 for ; Fri, 10 Feb 1995 17:21:10 -0800 Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.8/8.6.6) id RAA25167; Fri, 10 Feb 1995 17:20:45 -0800 From: "Rodney W. Grimes" Message-Id: <199502110120.RAA25167@gndrsh.aac.dev.com> Subject: Re: MIT SHM X11 extensions? (fwd) To: peter@bonkers.taronga.com (Peter da Silva) Date: Fri, 10 Feb 1995 17:20:44 -0800 (PST) Cc: hackers@FreeBSD.org In-Reply-To: <199502110003.SAA23105@bonkers.taronga.com> from "Peter da Silva" at Feb 10, 95 06:03:35 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1054 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > Actually, you could fault the whole image to swap and close the > > reference to the file -- and just allow the write, with never an > > ETXTBUSY to be seen. > > I consider the sudden explosion of swap utilization to be a surprising > consequence, especially considering the size of some images. When you're > writing to an image you're likely replacing it with "install" anyway. > Let "install" detect the ETXTBSY and do a little shuffle. Install always does an unlink so it handles this problem just fine: /* * Unlink now... avoid ETXTBSY errors later. Try and turn * off the append/immutable bits -- if we fail, go ahead, * it might work. */ #define NOCHANGEBITS (UF_IMMUTABLE | UF_APPEND | SF_IMMUTABLE | SF_APPEND) if (to_sb.st_flags & NOCHANGEBITS) (void)chflags(to_name, to_sb.st_flags & ~(NOCHANGEBITS)); (void)unlink(to_name); } -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD