What is the point of having a key_t if what will be the key to access shared memory is the return value of shmget()?

Posted by devoured elysium on Stack Overflow See other posts from Stack Overflow or by devoured elysium
Published on 2010-11-13T23:54:13Z Indexed on 2012/11/28 11:04 UTC
Read the original article Hit count: 135

Filed under:
|
|

When using shared memory, why should we care about creating a key

key_t ftok(const char *path, int id);

in the following bit of code?

key_t key;
int shmid;

key = ftok("/home/beej/somefile3", 'R');
shmid = shmget(key, 1024, 0644 | IPC_CREAT);

From what I've come to understand, what is needed to access a given shared memory is the shmid, not the key. Or am I wrong? If what we need is the shmid, what is the point in not just creating a random key every time?

Edit

@link text one can read:

What about this key nonsense? How do we create one? Well, since the type key_t is actually just a long, you can use any number you want. But what if you hard-code the number and some other unrelated program hardcodes the same number but wants another queue? The solution is to use the ftok() function which generates a key from two arguments.

Reading this, it gives me the impression that what one needs to attach to a shared-memory block is the key. But this isn't true, is it?

Thanks

© Stack Overflow or respective owner

Related posts about c

    Related posts about unix