Chandra
Chandra

Reputation: 309

Shared memory API, where a process can attach shared memory to other process

Can any one look into this and suggest me with an API.

We have APIs for a process which can create and/or attach a shared memory to its own process. But I don't find an API to attach a shared memory to one process by other process(for e.g., process A should call one API(like shmat()) to attach the shared memory to process B).

Upvotes: 0

Views: 1720

Answers (3)

J-16 SDiZ
J-16 SDiZ

Reputation: 26930

You are asking to attach the process memory of other process, right?

Just open(2) the file /proc/<pid>/mem and use it. Check the /proc/<pid>/map for the list of usable address in the file.

Upvotes: 0

Nim
Nim

Reputation: 33655

Let's see, allow one process to force a shared memory segment on to another? What is the receiver going to do with it? How will it know it now has mapped this block in - what is expected of it.

You're thinking about the problem the wrong way - simply hoisting a block of memory on to a second process is not going to allow you to do what you want. You need to notify the second process also that it has now mapped this block and so can start doing stuff with it. I suggest you take a step back and really look at your design and what you are doing. My recommended approach would be

  1. A connects to B via some other IPC (say socket)
  2. A informs B that it should attach with the details (name etc.)
  3. B then attaches - and now B is aware of it and can start doing stuff with it. (say for example once the attach completes, B confirms to A, and then they can start talking over the shared memory block).

As for wrapping shared memory in a nice library - consider boost::interprocess.

Upvotes: 0

paxdiablo
paxdiablo

Reputation: 882806

Shared memory doesn't belong to any particular process (unless you create it with a private IPC_PRIVATE key). It belongs to the system.

So, when you use shmget with a non-private key (and the IPC_CREAT flag), you will either create a shared memory block or attach to an existing one.

You need a way for both processes to use the same IPC key and this is often done by using ftok which uses a file specification and an identifier to give you an IPC key for use in the shmget call (and other IPC type calls, such as msgget or semget).

For example, in the programs pax1 and pax2, you may have a code segment like:

int getMyShMem (void) {
    key_t mykey = ftok ("/var/pax.cfg", 0); // only one shm block so use id of 0
    if (mykey == (key_t)-1)                 // no go.
        return -1;
    return shmget (mykey, 1024, IPC_CREAT); // get (or make) a 1K block.
}

By having both processes use the same file specification and ID, they'll get the same shared memory block.

You can use different IDs to give you distinct shared memory blocks all based on the same file (you may, for example, want one for a configuration shared memory block and another for storing shared state).

And, given that it's your configuration file the IPC key is based on, the chances of other programs using it is minuscule (I think it may be zero but I'm not 100% sure).

You can't forcefully inject shared memory into a process from outside that process (well, you may be able to but it would be both dangerous and require all sorts of root-level permissions). That would break the protected process model and turn you system into something about as secure as MS-DOS :-)

Upvotes: 1

Related Questions