Date: Tue, 10 Dec 1996 20:05:46 +0100 (MEZ) From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at> To: scrappy@hub.org (Marc G. Fournier) Cc: erich@lodgenet.com, hackers@freebsd.org Subject: Re: Multiple Buffer allocation of Shared Memory Message-ID: <199612101905.AA193564746@ws2301.gud.siemens.co.at> In-Reply-To: <Pine.NEB.3.95.961210130845.374A-100000@hub.org> from "Marc G. Fournier" at Dec 10, 96 01:20:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
E-mail message from Marc G. Fournier contained: > On Mon, 9 Dec 1996, Eric L. Hernes wrote: > > > "Marc G. Fournier" writes: > > > > > >Hi... > > > > > > Just starting to play with shared memory, and have hit a wall > > >that I don't know if its too be expected, or if I've screwed something > > >up... > > > > Shared memory is cool, SysV symantics for shared memory *suck*, if at all > > possible use mmap(). BSDi uses libc wrappers around mmap() for > > it's SysV shm stuff, but there's caveats... I'd like the wrappers, > > but have the real ones available too. > > > > 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). mmap with MAP_SHARED will "propagate" the writes among all processes who map is as shared. You can map with MAP_ANON as well which ignores the contents of the fd (but you still have to have it opened; /dev/null comes in handy :) /Marino > > Is there something I'm missing? With shared memory, this isn't a > problem, or, at least, from what I've read, won't be a problem... > > > #ifndef SHMSEG > > #define SHMSEG 8 > > #endif > > > > you can only have 8 shm segments by default, you can override > > it with: `options "SHMSEG=32"' or something similar in your config file. > > I usually bump SHMSEG to 128 and SHMMAXPGS to 4096. > > > > Did this, got this: > > ----- > 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. > > options SYSVSHM > options SYSVSEM > options SYSVMSG > options "SHMSEG=256" > options "SHMMAXPGS=4096" > > Marc G. Fournier scrappy@hub.org > Systems Administrator @ hub.org scrappy@freebsd.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612101905.AA193564746>