Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!ritcv!cci632!crp
From: crp@cci632.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Motorola shared memory questions
Message-ID: <2581@cci632.UUCP>
Date: Thu, 3-Dec-87 13:52:58 EST
Article-I.D.: cci632.2581
Posted: Thu Dec  3 13:52:58 1987
Date-Received: Sun, 6-Dec-87 17:21:16 EST
References: <106600017@datacube> <106600019@datacube>
Organization: CCI, Communications Systems Division, Rochester, NY
Lines: 52
Summary: Be wary of the direction of the "next" segment ...

In article <106600019@datacube>, ftw@datacube.UUCP writes:
> 
> When I call shmat() for the first time, use a NULL arg. for the attach
> address; shmat() gives out virtual addresses that are always (shared memory)
> block aligned, even if the corresponding shmat() asked for a smaller chunk
> of memory.
> 
> Successive calls to shmat() should have an arg of whatever the first shmat()
> returned for the virtual address, plus the number of bytes requested so far.
				    ^^^^

Be warned that some implementations allocate segments like this
(i.e. progressively higher addresses), while others allocate segments
from higher to lower addresses. In which case, the virtual address of the
second and subsequent segments the address of the previous segment *minus*
the *size* of that segment. Note that in this scenario, the address of the
contiguous memory is actually the address of the *last* segment allocated;
while with progressive addresses it's the address of the *first* segment.

In any case, you should always attach any partial segment required last
(i.e. size_of_all_shared_memory % segment_size), so that all segments
are properly aligned. For example, to attach 600,000 bytes of shared
memory on a machine with 128K segments and progressive addresses:

	start = attach 128K segment at first available address
	nextaddr = start + 128K
	nextaddr = attach 128K segment at nextaddr
	nextaddr += 128K
	nextaddr = attach 128K segment at nextaddr
	nextaddr += 128K
	nextaddr = attach 128K segment at nextaddr
	nextaddr += 128K
	nextaddr = attach 88000 byte segment at nextaddr
	return(start)

> This ensures a nice, flat virtual address space.
> 
> Jonathan Creighton (pyrnj!oracle!jcreight) has an interesting suggestion:
> he suggests that I choose a virtual address that is closer to the midpoint
> between the current stack and heap, so that I won't run out of space for
> malloc() or lotsa nested funtion calls.

Also be warned that dynamic stack growth or heap growth can trash (or detach)
shared memory in certain implementations. You'll have to test your own
configurations to learn this. An easy way out of problems like this is to
pre-allocate stack and heap by calling an initialization function with 
*lots* of local variables (to grow the stack) and then malloc(lots_of_mem).

Chuck Privitera		(... !rochester!cci632!crp)
Computer Consoles Inc.
Rochester, New York
variable