Re: Shared Memory and Distributed Objects
Re: Shared Memory and Distributed Objects
- Subject: Re: Shared Memory and Distributed Objects
- From: Kaelin Colclasure <email@hidden>
- Date: Sun, 16 Feb 2003 12:00:24 -0800
On Sunday, February 16, 2003, at 03:37 AM, Dan Bernstein wrote:
Hi,
I'm taking my first steps with distributed objects, and I'm looking
for an *efficient* way to make a large (~1MB) area of one process's
memory available to a second process for reading. Here's what I've
tried so far:
1. Using a shared memory object, opened with shm_open() and mapped
with mmap().
Problem: no matter what I did, I couldn't get mmap() to accept the fd
shm_open() had returned.
mmap() is not used with System V shared memory objects (AFAIK). The fd
mmap() wants is a normal filesystem file handle.
2. Using a shared memory area obtained with shmget() and mapped with
shmat().
Problems: a. shmget() didn't work with large values of size. I don't
want to separate the memory into chunks.
b. How am I supposed to pick a value for key? Try a random value and
hope it's free?
It would be even better if I could wrap my memory in an NSData and
vend it, however I'm concerned that this is implemented in such a
(clever) way that even though the entire area of memory isn't copied
as soon as the object is vended, whenever the vending process writes
to the area afterwards the relevant memory page is duplicated and the
writing appears only in that process's space, so that the client keeps
seeing the memory as it was at the time the NSData was vended.
Is there a way to do what I want using DOs? If not, can the problems
in 1. or 2. above be overcome?
I'm not terribly familiar with Next-flavor DO, but in general DO
systems are not tailored for the behavior you're describing. They are
by design providing a general *distributed* solution, ergo generally
they stick to implementing things that will work between machines
across a network.
From what you've described, I'd suggest delving a bit deeper into
mmap(). This deceptively simple system call opens up access to the VM
and swap machinery of the kernel. mmap() is the API of choice for
sharing memory between processes. For example, it's how the operating
system manages shared libraries. And because it is such a thin veneer
over the kernel VM system, it can be counted on to behave reliably and
predictably with no special tweaking or tuning.
(I have yet to see an application that made non-trivial use of System V
IPC resources that did not also come with an extensive set of release
notes explaining how to tweak various kernel parameters to achieve
usable results.)
-- Kaelin
Many thanks in advance,
-- Dan Bernstein
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.