Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!pyrnj!mirror!rayssd!dpw
From: dpw@rayssd.UUCP (Darryl P. Wagoner)
Newsgroups: net.unix-wizards
Subject: Re: System V shared memory and Ultrix ?
Message-ID: <168@rayssd.UUCP>
Date: Thu, 25-Sep-86 11:05:38 EDT
Article-I.D.: rayssd.168
Posted: Thu Sep 25 11:05:38 1986
Date-Received: Fri, 26-Sep-86 20:18:47 EDT
References: <547@rna.UUCP> <548@rna.UUCP>
Sender: dpw@rayssd.UUCP (Darryl P. Wagoner @ Raytheon Co., Portsmouth RI)
Organization: Raytheon Co., Portsmouth RI
Lines: 58

> However I'm still confused
> about a number of the facilities of shm*(). For example, what role does "key"
> play ? How do I pass the shared memory segment to non-related process ?
> 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 ?

Let me start by saying that I am no expert on shared memory.  STDIPC(3C) is the 
System V standard for IPC.  The only routine that is currently in the stdipc
package is ftok, which when called and passed a file name and an "id", it 
returns a unique key in key_t (long int) format.  The key is based on the 
id (8 bits) minor device name (8 bits) and the inode number (16 bits).  By 
different processes knowing what file name and "id" that was passed to ftok, 
they can get the same key and therefore access the same shared memory.  The 
trick is to insure that all IPC programs adhere to this standard.  

> 	Is the shared memory segment automatically destroyed if no process has
> it "open" ? 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.

No, once shmget is called, the shared memory identifier will remain until one 
of two things happen.  First shmctl is called to remove it.  Second the system 
is rebooted.  

This is what I believe, but I could very well be wrong.  The shmget call creates
an entry for the key in a shared memory table (link list I would guess).
That contains the shared memory identifier, the key, a pointer to
the shared memory and the rest of the shared memory information.  
Shmat() attaches a segment to the shared memory identifier.

The question that I have is, if you call shmat with the address of a 
segment in your program, will that segment dry up and blow away when you 
program exited.  I know the shared memory identifier will remain.

> 	shmflg = IPC_CREAT + 0666;
> 	key = IPC_PRIVATE;

	key = ftok("/usr/bin/lint",'a');  
	/* if the file is change (as in remove then recreated) it will change
		the key that is returned */

Damn it Jim, I am a programmer, not a Englist Major

	Darryl Wagoner
	Raytheon Co.; Portsmouth RI; (401)-847-8000 x4089

best path             {allegra|gatech|mirror|raybed2}  ---------\
next best             {linus|ihnp4|pyrbos} ---------------------->!rayssd!dpw
if all else fails     {brunix|cci632} -------------------------/

-- 
	Darryl Wagoner
	Raytheon Co.; Portsmouth RI; (401)-847-8000 x4089

best path             {allegra|gatech|mirror|raybed2}  ---------\
next best             {linus|ihnp4|pyrbos} ---------------------->!rayssd!dpw
if all else fails     {brunix|cci632} -------------------------/