Date: Tue, 10 Dec 1996 13:35:24 -0600 From: "Eric L. Hernes" <erich@lodgenet.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: "Eric L. Hernes" <erich@lodgenet.com>, hackers@FreeBSD.ORG Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612101935.NAA16873@jake.lodgenet.com> In-Reply-To: Your message of "Tue, 10 Dec 1996 13:20:06 EST." <Pine.NEB.3.95.961210130845.374A-100000@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Marc G. Fournier" writes:
>
> Okay...maybe I'm missing something as far as mmap() is concerned,
>but what I want to be able to do is allocated X bytes of memory to be
>shared amongst several processes. After the memory is allocated, I will
>*then* want to fill the memory (ie. with data read from a socket).
>
> From reading the mmap() man page (any good reference/textbooks that
>I might want to pick up?), mmap() allocates and fills the memory space at
>the same time, based on a previously opened, already existing, file (fd).
>
Yup,
* The Design and Implemenatation of the 4.4BSD Operating System
~page 139
* UNIX Internals The New Frontiers
~page 440
One way, is to open a (previously agreed upon) named file that
will be used to share data, ftruncate() it to the size you want,
then mmap() it. Other processes can open and mmap() this same file
to get at the data. After the mmap(), you've got a pointer to the
data, you can cast it to whatever you like, just like with shmat().
The biggest problem here is that all programs will have to agree
on the named file, but if you use the SysV stuff, they all have to agree
on the shmid, so it's not a showstopper. Terry has already outlined
a solution that avoids this problem. In a nutshell, open()/mmap()
are roughly analogous to shmget()/shmat(), and munmap()/unlink()
are roughly analogous to shmget()/shmctl(). One thing that named files
and mmap() can buy you is persistance of data across a reboot(), whether
that is good or bad is up to you.
>
>-----
>hub> ./client
>No space left on device
>cannot initialize shared memory buffer #29
>-----
>
> At least I'm getting 28 buffers created now, instead of just
>8 :)
>
> Now, am I understanding what I've configured correctly? With
>SHMSEG=128 and SHMMAXPGS=4096, I should be able to allocate up to 128
>pages of 4096k each? I actually set SHMSEG to 256, mind you...just in case.
SHMMAXPGS is in pages, so its 4096*4096, or 16Meg. I think that 16Meg is
the global shared mem pool, and the 128 segments are taken out of it.
As John has pointed out, the numbers are purely administrative, you may
be able to remove the checks in kern/sysv_shm.c and just grant the requests,
but you'll have to check the return from the lower (vm) layer that acutally
returns the mapping.
>
>Marc G. Fournier scrappy@hub.org
>Systems Administrator @ hub.org scrappy@freebsd.org
>
eric.
--
erich@lodgenet.com
http://rrnet.com/~erich erich@rrnet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612101935.NAA16873>