shared memory

[Jeremy J. Epstein]

In article <1989Dec12.005555.20618 at virtech.uucp>, cpcahil at virtech.uucp (Conor P. Cahill) writes:
> In article <11383 at csli.Stanford.EDU>, poser at 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