Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!aplcen!uunet!virtech!jje
From: jje@virtech.uucp (Jeremy J. Epstein)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Summary: can't always pick where to attach a shared memory segment
Keywords: portability
Message-ID: <1989Dec15.221201.1003@virtech.uucp>
Date: 15 Dec 89 22:12:01 GMT
References: <11383@csli.Stanford.EDU> <1989Dec12.005555.20618@virtech.uucp>
Organization: Virtual Technologies Inc.
Lines: 41

In article <1989Dec12.005555.20618@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> In article <11383@csli.Stanford.EDU>, poser@csli.Stanford.EDU (Bill Poser) writes:
> > [stuff deleted]  However, I have discovered that
> > two crucial parameters differ widely from system to system and
> > that there appears to be no way to change them other than
> > rebuilding the kernel, which is not always an option.
> 
> Modifying the SHMMAX should only require a kernel re-configuration which
> should always be an option.
Not true, Conor...some systems don't have C compilers, linkers, etc
which are needed to do reconfiguration.  Many XENIX systems are that way.
 
> An easy mechanism to handle this problem [leaving enough room for the
> sbrk] is to do the following:
> 
> 	get the current sbrk value;
> 	create the shared memory segment
> 	attach the segment at the default address.
> 
> 	if this address is too close to the sbrk value
> 		detach the segment
> 		attatch the segment at sbrk+min_size_that_you_need
Unfortunately this doesn't work on some machines.  For example, on
HP RISC machines (the 9000/8xx systems), the address you get attached
at in fact identifies the segment.  Thus, no two shared memory segments on
a system will have the same address.  This prevents you from ever
attaching at an address other than the default.  I complained about
this a few years ago, and was pointed to the place in the manual
(presumably on the shmat(2) page) where it warned of this "feature".

I agree with Bill Poser: there is no uniformity to this feature, or
how to use it.

Jeremy Epstein
TRW Systems Division
uunet!virtech!jje
-- 
Jeremy Epstein
TRW Systems Division
2750 Prosperity Avenue
FV10/5010