shared memory

James Shankland jas at postgres.uucp
Tue Dec 12 05:26:33 AEST 1989


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....  Two crucial parameters differ widely from system to system ...:
>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....

UNIX shared memory support remains polymorphically perverse.  Not only
is the whole SysV shmem interface a botch, but the implementations are
flawed.  Your application should certainly be coded so that it can live
with different amounts of shared memory on different platforms, and
with different attachment addresses.  Also, remember that you can
override default segment placement in the shmat() call to get a bigger
sbrk() region.

Though I haven't used it, the SunOS4.x mmap interface seems like a much
more rational approach to shared memory.  Can anyone comment on its
usefulness and its future?  Also, are there incompatibilities between
Sun's mmap and that of other vendors (doesn't Sequent have an mmap
interface, too?), and the unimplemented mmap() described in the 4.2 docs?

jas



More information about the Comp.unix.wizards mailing list