Date: Fri, 13 Dec 1996 08:04:23 -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: <199612131404.IAA08338@jake.lodgenet.com> In-Reply-To: Your message of "Fri, 13 Dec 1996 00:47:09 EST." <Pine.NEB.3.95.961213002725.14115D-100000@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Marc G. Fournier" writes: > > The one question that I can't seem to find addressed though is >opening the named file. > > Now, since I'm closing the file after MMAP'ng it, does it matter >how I open it? I incorrectly used the terms 'child/parent' when I first >asked...the reason I'm going named file is because its a client/server >environment...sorry if that changes everything, but from what I've >read, I don't think it does... > Are these true parent/children, or server/client. It doesn't change *everything*, mostly it just throws out some of the shortcuts, like inheriting file descriptors and/or mmap'd regions. > Now, if I understand it correctly, what I'm goin to want to do is: > >parent: > > open named file (O_RDONLY, O_RDWR, or it doesn't matter?) I think there's a correspondence between the file mode and the PROT_*, specifically, if you open a file O_RDONLY, then mmap with PROT_WRITE, the mmap will fail with EACCES. > ftruncate named file > mmap it using something similar to: > mmap(0, <size of file>, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > close named file > >child: > > open named file (again, does the mode matter?) > mmap it using something similar to: > mmap(0, <size of file>, PROT_READ, MAP_SHARED, fd, 0); > close named file > > Is that the gist of it? Then I can "read/write" the mmap'd area >just like I would a similarly malloc()'d area, correct? > Yes, that looks ok. To update the image on disk, you'll need to use msync(). I'm not sure if there's ever a predictable implicit msync(). Certainly when memory is scarce, but that's not predicable. Possibly when munmap'ing, or at process exit. > >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?199612131404.IAA08338>