shared memory

[Gil Pilz@Eng@Banyan]

In article <11383 at csli.Stanford.EDU> poser at 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. 

[stuff removed]

>rebuilding the kernel, which is not always an option. The two
>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 distance determines the maximum amount of ordinary
>(non-shared) memory that a program can (s)brk. 

For every implementation of shmat(2) that I've seen you are allowed to
specify where in the virtual memory map you wish to attach the shared
region.  The parameter you speak of only serves as a _default_ in
cases where you don't really care and specify '0' as the attach
address (it might also serve as a lower limit to make sure you don't
screw yourself out of (s)brk space).

The other parameter you mention (maximum size of a shared region) can
usually only be re-configured if have the ability to rebuild the
kernel. If this is not an option you may be able to patch the sucker
but it's really flavor dependent at that point (the main questions
being (a) wether the routine that creates shared regions simply checks
against this upper limit or wether there are some pre-allocated
structures that depend on the upper limit being what it is, and (b)
wether or not the rest of the virtual memory sub-system can cope with
changes to this size).

"I've got two hundred miles of gray asphalt and lights before I sleep
 and there'll be no warm sheets or welcoming arms to fall into tonight
 I've got two hundred miles of gray asphalt and lights before I sleep
 but I wouldn't trade all your golden tomorrows for one hour of this night"
	- cowboy junkies

Gilbert W. Pilz Jr.       gil at banyan.com