Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Feb 1999 22:25:29 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        dyson@iquest.net, dg@root.com, kuku@gilberto.physik.RWTH-Aachen.DE, hackers@FreeBSD.ORG
Subject:   Re: portability of shm, mmap, pipes and socket IPC
Message-ID:  <199902110625.WAA88612@apollo.backplane.com>
References:   <199902110220.TAA08932@usr06.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
:> 
:>     ... and has absolutely nothing to do with the question that John was 
:>     replying to, which was related to the fault overhead/expense of using
:>     mmap() verses a SYS-V shared memory segment.
:
:But has everything to do with his statement to the effect that
:"There is no effective difference", contained in the answer.  The
:rest was quoted for context.  I am not so stupid that I cannot
:fathom his answer, as you would see if you read the rest of the
:messages in this thread, where I said "Mea culpa" ("My Fault") to
:David's quotation of John's reply in a different context.
:
:
:					Terry Lambert
:					terry@lambert.org

    The issue of file-backed storage verses anon mmap is certainly real,
    but it's divergent enough from the original discussion that it should
    have been brought up as a separate item rather then as a response,
    That's all.

    This brings up a good point, though... I think it might make sense 
    to be able to specify a MAP_ flag to mmap to indicate that the file's
    dirty data backing the map ( for non-anonymous maps ) does not have to 
    be synced by the syncer.  That would make mmap() a much more useful
    tool for sharing working sets.  The file data would be synced on the 
    last close of the vnode and if the program really doesn't want it to be
    synced at all, the program could madvise() it free ( and we could fix
    madvise() to actually support throw-away on a vnode ).

    Another possibility would be adding a memory reference passing capability
    to unix-domain socket messaging.  We can already pass descriptors and 
    access rights, why not memory too? ( ala mach ).

					-Matt

					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902110625.WAA88612>