From owner-freebsd-arch Tue Jan 14 10:34:44 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1264D37B401 for ; Tue, 14 Jan 2003 10:34:43 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 919B843F65 for ; Tue, 14 Jan 2003 10:34:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0EIYg0i081142; Tue, 14 Jan 2003 10:34:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0EIYgD4081141; Tue, 14 Jan 2003 10:34:42 -0800 (PST) Date: Tue, 14 Jan 2003 10:34:42 -0800 (PST) From: Matthew Dillon Message-Id: <200301141834.h0EIYgD4081141@apollo.backplane.com> To: Gary Thorpe Cc: freebsd-arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: <20030114142450.57943.qmail@web41215.mail.yahoo.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :A quick note: I don't think its a "race condition" necessarily, but it :is purposefully designed that way: processes have to remove shared :memory segments themselves and they may die before doing so. If your :program exits normally after creating a SysV shared memory segment :without removing it, it will stay around (I suppose because it is :globally accessable by processes having the right key). Perhaps a sort :of garbage collection scheme for it would be useful (i.e. if reference :count reaches zero [all the mapping processes have exited], delete it), :but then suppose you want data to persists in it? Same for SysV :semaphores and message boxes I think. The most common sysv shared memory operation is to create a private shared memory segment for a program while it is running. You normally do this by creating the segment, mapping it, and then removing the segment. Deleting the segment does not removing the mapping, it simply causes the kernel to physically remove the segment once the last reference to it has gone away. There is a race during this create/map/delete process. If the process is killed after the create but before it manages to delete the mapping, the mapping remains in the shm tables (ipcs -a). A far better solution to this common scenario is to have a filesystem rendezvous, like a FIFO (see mkfifo), where the kernel simply blows everything away after the last reference has disappeared, or to have a descriptor-based rendezvous which has the same effect when the descriptor is closed (and all mappings have gone away) for the last time. :The third solution is anonymous mappings via mmap(), but I only think :that can be shared by parent and children after fork(). Is there a way :to share this with non-related (in terms of fork() hierarchy) :processes? No. Well, there might be a trick that could be played with exec(), but basically no. Even depending on fork() is not reliable. FreeBSD supports shared memory on fork(), but it isn't guarenteed across all available unix architectures (i.e. on some UNIX systems you can't have MAP_SHARED memory across a fork and the space becomes copy-on-write). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message