Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!swrinde!emory!europa.eng.gtefsd.com!uunet!Germany.EU.net!isaak.isa.de!nadia.stgt.sub.org!ncc1701.stgt.sub.org!ncc1701!space From: space@ncc1701.stgt.sub.org (Lars Soltau) Newsgroups: comp.unix.bsd Subject: mmap(2) semantics Date: 21 Nov 1993 09:06:42 GMT Organization: United Federation of Planets Lines: 17 Message-ID: <SPACE.93Nov21100643@ncc1701.stgt.sub.org> NNTP-Posting-Host: ncc1701.stgt.sub.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit What are the exact semantics of the mmap(2) system call? To elaborate, I'm having the following problem: In BSD/386, any changes you make to the mapped memory do not reflect on the actual disk file until you call msync(2), even if you set the MAP_SHARED flag on mapping the file. The inn sources do not seem to expect this behaviour, either in the dbz code or in the code handling the active file. I had to add msync(2) calls in strategic locations so that changes would actually reflect on the disk file. Is this behaviour correct? Is there a definition on what the correct behaviour would be? -- Lars Soltau bang: <insert ridiculously long path> BIX: -- no bucks -- smart: space@ncc1701.stgt.sub.org Will kein Gott auf Erden sein, sind wir selber Götter.