Date: Tue, 10 Dec 1996 15:11:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: erich@lodgenet.com (Eric L. Hernes) Cc: scrappy@hub.org, erich@lodgenet.com, hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612102212.PAA05068@phaeton.artisoft.com> In-Reply-To: <199612102125.PAA17784@jake.lodgenet.com> from "Eric L. Hernes" at Dec 10, 96 03:25:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> *But* if you have a child that > needs access to a memory segment that the parent doesn't allocate until > after the fork, you'll need something like Terry's fd passing trick, or > the well known file trick in order to get the memory. I was worried about the "nothing to inherit case", where one process accessing the segment wasn't in the same process group or hierarchically related in any way to the process that created the segment. > In theory yes, but mmap is much faster than open/read/close, for one > reason, there's fewer system calls. For another, the work of mmap > is done through the VM system, which may or may not read the information > from disk, although in theory the buffer cache should prevent the read() > from going to disk too. Also a socket write of an mmap'ed space avoids the bmap() translation on systems without a unified VM/cache. Since the mapping already exists, the translation can be done statically... the kernel space address and user space address don't need the checking. We used this on SVR4 all the time to avoid lots of copies for user space servers for net clients (http, NetWare, and AppleTalk). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612102212.PAA05068>