Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <1989Dec12.005555.20618@virtech.uucp>
Date: 12 Dec 89 00:55:55 GMT
References: <11383@csli.Stanford.EDU>
Organization: Virtual Technologies Inc.
Lines: 45

In article <11383@csli.Stanford.EDU>, poser@csli.Stanford.EDU (Bill Poser) writes:
> In attempting to use shared memory for large (hundreds of KB) 
> objects, I have run into what seem to be nearly insuperable portability
> problems. At first I was optimistic, as the System V shared memory
> facilities seem to have spread to most versions of UNIX, without
> even any differences in syntax. 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. The two

Modifying the SHMMAX should only require a kernel re-configuration which
should always be an option.

> parameters are the maximum size of a shared memory segment and
> the separation between the end of the program's data segment and
> the virtual address at which shared memory segments are attached. 

This would require a kernel rebuild, however if you design you're software
correctly, there won't be any problems.

An easy mechanism to handle this problem 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

If you don't know how much sbrk room to leave, just pick a big number. The 
only detriment will be that your process will take up a few extra page 
table entries.

> 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?

No, you just need to adjust things a bit.

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