Path: utzoo!utgpu!watserv1!watmath!att!dptg!ulysses!andante!mit-eddie!snorkelwacker!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!sauron!wescott
From: wescott@Columbia.NCR.COM (Mike Wescott)
Newsgroups: comp.sys.ncr
Subject: Re: Tower 32 - SHMBRK
Keywords: SHMBRK malloc sbrk
Message-ID: <2227@sauron.Columbia.NCR.COM>
Date: 16 Jul 90 00:58:02 GMT
References: <396@bohra.cpg.oz>
Sender: news@sauron.Columbia.NCR.COM
Reply-To: wescott@micky.Columbia.NCR.COM (Mike Wescott)
Organization: E&M-Columbia, NCR Corp, W Columbia, SC
Lines: 26

In article <396@bohra.cpg.oz> rod@bohra.cpg.oz (Rod Bruce) writes:
> Under V.3 however, the SHMBRK parameter does not exist (at least, I can't find
> it anywhere) and so I was wondering -
> 	1. How does the system decide where to place shared memory segments?

It picks the next convenient segment boundary.  On the 200 and 700
that means the first shmat will go at 0x4000000 and the next at 0x6000000

On a 6xx, it means the first goes at 0x200000.

> 	2. Can we run out of malloc space?

Yes.  At least on the 6xx.  On the ohters there's 32Mb for your
data, bss and heap.  On the 600 it's only 1Mb.

> 	3. Is there anything we can do to ensure that (2) does not happen?

There's always the non-portable define the attach address yourself.

	-Mike

PS.  This was ascertained by experimentation rather than perusal of the
code.
--
	-Mike Wescott
	 mike.wescott@ncrcae.Columbia.NCR.COM