Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!ames!oliveb!sun!fatkid!dss
From: dss@fatkid.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Question about Sys V shared memory
Message-ID: <15619@sun.uucp>
Date: Wed, 25-Mar-87 13:46:02 EST
Article-I.D.: sun.15619
Posted: Wed Mar 25 13:46:02 1987
Date-Received: Fri, 27-Mar-87 04:31:43 EST
References: <314@nbc1.UUCP>
Sender: news@sun.uucp
Reply-To: dss@sun.UUCP (Daniel Steinberg)
Organization: Sun Microsystems, Mountain View
Lines: 54
Keywords: shared memory, SVID

In article <314@nbc1.UUCP> abs@nbc1.UUCP (Andrew Siegel) writes:
>
>If process A attaches the shm segment and assigns an address within
>the segment's memory pool to one of these pointers, will this
>address have any meaning to other processes that attach the
>segment?
>

The SystemV Interface Definition (SVID) [and AT&T's SystemV implementation]
specify the shmat() interface with an 'shmaddr' argument that may be either
an address at which to attach the shared-memory segment or zero (specifying
that the kernel should pick an address at which to attach the segment).

As such, if all processes attached the shared memory segment at the same
address, then absolute pointers into the segment would work.  However,
this is not a portable construct, for several reasons:

1) The SVID does not specify how you can determine the range of valid
   addresses for a shmat() operation.  It does not even say whether the
   address range may be mapped already (e.g., a block of malloc'ed bytes),
   although AT&T SystemV only allows you to attach shared memory at an
   address that is inbetween your current brk()-point and your stack.
   Other implementations might only allow shared memory to be attached
   at an address range that is already mapped in the data space of the
   process.

   By the way, the AT&T SystemV Programmer's Guide says, on page 9-104,
   "If [shmaddr] is user supplied, the address must be a valid address
    that the UNIX operating system would pick....It would be wise to
    let the operating system pick addresses so as to improve portability."

   [A portable way to use the 'supplied address' feature might be to
    attach a segment with a zero address, detach the segment, then
    reattach the segment at the same address that was returned before.
    But that isn't a very interesting use of this feature.]

2) There are some UNIX implementations that provide shared memory,
   but cannot support the 'attach at given address' feature, either
   because of machine architecture limitations or the virtual-memory
   implementation.

If you can structure your application such that all cooperating processes
share common source, then you could have a process attach the shared
memory segment and fork (shared memory mappings are preserved across fork(),
but not exec()).  Or, if you were only concerned about running your
application on specific implementations of AT&T SystemV, you could depend
on the 'attach at given address' feature and to hell with portability.
In general, however, it is a better practice to use offsets into shared
segments, rather than absolute pointers, to do what you're trying to do.

	Daniel Steinberg
	Sun Microsystems, Inc.
	ihnp4!sun!dss
	(415) 691-7531