From owner-freebsd-arch Tue Jan 14 6:24:53 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 1163837B401 for ; Tue, 14 Jan 2003 06:24:51 -0800 (PST) Received: from web41215.mail.yahoo.com (web41215.mail.yahoo.com [66.218.93.48]) by mx1.FreeBSD.org (Postfix) with SMTP id 80ECB43F75 for ; Tue, 14 Jan 2003 06:24:50 -0800 (PST) (envelope-from gathorpe79@yahoo.com) Message-ID: <20030114142450.57943.qmail@web41215.mail.yahoo.com> Received: from [24.114.70.137] by web41215.mail.yahoo.com via HTTP; Tue, 14 Jan 2003 09:24:50 EST Date: Tue, 14 Jan 2003 09:24:50 -0500 (EST) From: Gary Thorpe Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) To: Matthew Dillon , freebsd-arch@freebsd.org In-Reply-To: <200301140851.h0E8p78U078882@apollo.backplane.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 --- Matthew Dillon wrote: > > : > :Matthew Dillon wrote: > :> > :> This is a first-attempt workup of getsysfd(). See? I told ya > it was > :> trivial! > : > :[ ... ] > : > :What does this uniquely do, which can be done no other way, again? > : > :-- Terry > > What Peter asked for (and what this does) is give you a > descriptor > that is associated with just a VM Object. You can then mmap() > the > descriptor, pass it to other processes and they can mmap() it > too. > > It's a way of doing swap-backed shared memory without having to > deal > with the filesystem. The only other solutions are: > > * SysV shared memory, which is not fun to manage and may have > weird > size limitations, and has a race condition where a process > dying > at just the wrong time may leave a shmem segment lying around > in > the kernel. 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. > > * A file, which uses the filesystem as backing store. Even with > MAP_NOSYNC a shared file still uses the filesystem as backing > store. > This is typically not what is desired. 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? > > > Another thing I would like to do is descriptor-based timers. So > instead > of being limited to just the stupid itimers, or interfering with > other > threads/libraries use of [i]timers, you can simply allocate your > own by > getting a timer descriptor and then doing cool things with it, > like > having it generate a custom signal or selecting on it or > kqueue'ing on > it etc... it's something UNIX has needed for a long time > actually. > > -Matt > Matthew Dillon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message