Date: Tue, 10 Dec 1996 14:14:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: scrappy@hub.org (Marc G. Fournier) Cc: erich@lodgenet.com, hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612102114.OAA04855@phaeton.artisoft.com> In-Reply-To: <Pine.NEB.3.95.961210151724.374T-100000@hub.org> from "Marc G. Fournier" at Dec 10, 96 03:29:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Now, "child" processes accessing that MMAP'd area...Terry (I believe?)
> mentioned passing the file descriptor through a socket from the parent to
> the child, which, to me, sounds okay if you have few children reading the
> mmap()'d region...but what I'm working on is going to require 1000's of
> child processes reading that mmap()'d region, and having 1 socket open for
> each child doesn't sound very efficient.
If it's a child process, just unmark "close on exec" with fcntl() and
the child will have the fd available anyway.
> You mention a named file in your example, so each frame could be
> called '001', '002'...'999', with the child processes accessing them
> sequentially, as they exist...but at that point, I may as well just write
> the date to 001, and have the child process open, read, close...
Better to have a file 999 * sizeof(frame) in length and map it once.
> I think what I'm still missing is that the way mmap() is being
> described is that it requires a file to work off of, and all that the
> benefit is is that each child can share the data from the same memory
> region...what I'm *trying* to accomplish is a completely "in memory"
> solution, without using something like MFS to get off of the physical
> device.
>
> I know that I'm currently missing something that is totally
> obvious to those that have a better understanding of mmap/shm...thanks
> for the patience...
All a file is is a FS name space name for a memory region.
The difference betweem shm/mmap mappings is that, in the limit, the
shm mappings use the swap area for swap store ("swap pager") and
the mmap mappings use the file space for swap store ("vnode pager").
Because of the VM/cache unification, there is no real difference
between one or the other (except you have to preallocate swap
as swap store, but you can dynamically allocate and deallocate file
space as swap store).
Practically, the shm stuff is mapped in KVM space and the mmap stuff
is not. This is an implemenation detail (it's worse to implement
address space mappings in the KVM space because it's already so
limited and has paging restrictions because of the processor protect
bits -- but it's possible and likely for this to fixed in a future
rev of FreeBSD).
Bottom line: using mmap keeps you from bumping up against compile time
limits.
Regards,
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?199612102114.OAA04855>