Date: Tue, 14 Jan 2003 15:17:36 -0800 From: Peter Wemm <peter@wemm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <tlambert2@mindspring.com>, "Alan L. Cox" <alc@imimic.com>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <20030114231736.DF9442A89E@canning.wemm.org> In-Reply-To: <200301140851.h0E8p78U078882@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. Also, it gives you a handle to hold data while temporarily unmapped. eg: you can implement a small movable mapped window into a larger object. With MAP_ANON and /dev/zero, when you unmap the pages they are gone. Also, we could use one of these beasties as a backing store for malloc(). Since the offset is persistent and has a sequence of page offsets it should avoid the map fragmentation. > 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. We use kqueue timers at work FWIW. Trying to use the system timers in some cases is painful, and the kqueue EVFILT_TIMER stuff (both on periodic and oneshot mode) is just damn convenient. Sure, it doesn't have the bells and whistles that you have commented out in sysfd.h, but what kqueue provides is exactly what we need. Allthough the features could be added to the already existing kqueue interface, I dont see much use for them - sys and virtual timebases are rather specialized and somewhat overkill for regular applications IMHO. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20030114231736.DF9442A89E>