Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!pyrdc!eliot!janm
From: janm@eliot.UUCP (Jan Morales)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <474@eliot.UUCP>
Date: 12 Dec 89 20:58:23 GMT
References: <11383@csli.Stanford.EDU>
Reply-To: janm@eliot.UUCP (Jan Morales)
Organization: Unitech Software, Inc., Reston, VA
Lines: 26

In article <11383@csli.Stanford.EDU> Bill Poser writes:
>Am I correct in concluding that one simply cannot use shared memory
>portably for large objects or if one may need to allocate large amounts
>of ordinary memory dynamically?

What I have found is that most kernels select some seemingly arbitrary
address between the top of the heap and the bottom of the stack when
attaching a shared memory segment when no address is supplied in the
`shmat' call.  In one case, we ran into the same problem you have
because the shared memory segment was being attached a mere 32K above
the top of the heap.  Since our program malloced more than 32K after
attaching the shared memory segment, the program behaved as if it had
run out of memory because `malloc' (or `sbrk') would bump into the
bottom of the segment.

Our solution was to use the `getrlimit' system call to find out the
maximum address the heap might reach (the highest possible break),
subtract the size of the desired shared memory segment from it, and have
the `shmat' call attach at the resulting address.  On the system in
question, `shmat' was supposed to take the address provided and round it
down to the next page.  This solved the problem on that particular
platform.  I'm sure this is not a universal solution.

Jan
-- 
{uunet,pyramid}!pyrdc!eliot!janm