Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!unisoft!dual!ptsfa!qantel!ihnp4!houxm!hropus!jrw
From: jrw@hropus.UUCP (Jim Webb)
Newsgroups: net.unix-wizards
Subject: Re: System V shared memory and Ultrix ?
Message-ID: <700@hropus.UUCP>
Date: Wed, 24-Sep-86 19:20:54 EDT
Article-I.D.: hropus.700
Posted: Wed Sep 24 19:20:54 1986
Date-Received: Thu, 25-Sep-86 08:00:50 EDT
References: <547@rna.UUCP> <548@rna.UUCP>
Organization: Bell Labs, Holmdel, NJ
Lines: 60

> >	Has anyone used the System V-style shared memory facility in
> >Ultrix-32m (Microvax II)

Since Ultrix-32m is "supposedly" SV compatible, I will comment on how
"real" SV shared memory works.

> about a number of the facilities of shm*(). For example, what role does "key"
> play ? 

The "key" is used to generate a unique, yet reproducable, shared memory
identifier for use by the current or any other process.  One way is to
use ftok().  This function is in SV, so I am hoping it is in Ultrix...
It takes two arguments and returns a key:

		ftok(file,proj)		key=ftok("/unix",'x');
		char *file;
		char proj;

You pass it a file name and any character you choose and it diddles with
the info in the inode of the file and combines it with the character and
returns a key.  Just choose a file that doesn't change often.

>        How do I pass the shared memory segment to non-related process ?

You just use shmget() to get the shmid and then pass it to shmat().  For
example, you could do:

			key=ftok("/unix",'x');
			shmid=shmget(key,SIZE,FLAGS);
			shmat(shmid,ADDR,FLAGS);

or even: shmat(shmget(ftok("/unix",'x'),SIZE,FLAGS),ADDR,FLAGS);	:-)

> Perhaps what I should do (it doesn't seem to be documented) is stick a non
> zero long in key and require that the communicating process shmget() with the
> same key. Right ?

You got it right!  I guess the Ultrix docs are worse than the SV ones :-)

> 	Is the shared memory segment automatically destroyed if no process has
> it "open" ?

No, for several reasons.  For example, a program might want to use a 
shared memory segment for initialization data instead of a file, or,
a program might store info in a segment, exit, and come back later to
process the info.

However, there are two FLAGs (at least on my vax) SHM_CLEAR and SHM_DEST
that clear the segment on the next attach and destroy it when no one is
attached to it, respectively.  cat /usr/include/sys/shm.h to see if they
are on you machine as well.

>              What constitutes the "open" - the shmget() or the shmat() ? If it
> isn't destroyed then probably the shmat() is the "open" and the shmget() is
> a lookup/create.

There really is no "open."  shmget() creates an identifier in the kernel.
When you shmat() a segment, you utilize the resource, eg memory.
-- 
Jim Webb             "Out of phase--get help"          ...!ihnp4!hropus!jrw