Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <1989Dec16.033528.2496@virtech.uucp>
Date: 16 Dec 89 03:35:28 GMT
References: <11383@csli.Stanford.EDU> <1989Dec12.005555.20618@virtech.uucp> <1989Dec15.221201.1003@virtech.uucp>
Organization: Virtual Technologies Inc.
Lines: 54

In article <1989Dec15.221201.1003@virtech.uucp>, jje@virtech.uucp (Jeremy J. Epstein) writes:
> 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.

These days, most vendors include a mechanism which allows a re-configure
without having to have the Development system.  I even worked on a system
where they delivered a shell program that used adb to patch the appropriate
variables in the kernel for configuration purposes because there was no other
way to do it without the development system.

> > 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".
		     ^^^^^^^^  You probably mean shmop(2)
> 
> I agree with Bill Poser: there is no uniformity to this feature, or
> how to use it.

I also agree that there is no uniformity, but I think there is a solution 
for most shared memory implementations.  If what you say is true for the
HP machines (of course I have no reason to doubt it) I would say that HP
must ensure that the default attach location is far enough away from 
the malloc region so that moving it would not be necessary or they have a 
broken implementation.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+