Date: Tue, 14 Jan 2003 09:24:50 -0500 (EST) From: Gary Thorpe <gathorpe79@yahoo.com> To: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-arch@freebsd.org Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <20030114142450.57943.qmail@web41215.mail.yahoo.com> In-Reply-To: <200301140851.h0E8p78U078882@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Matthew Dillon <dillon@apollo.backplane.com> 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 > <dillon@backplane.com> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030114142450.57943.qmail>