Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres!jas
From: jas@postgres.uucp (James Shankland)
Newsgroups: comp.unix.wizards
Subject: Re: shared memory
Keywords: portability
Message-ID: <20552@pasteur.Berkeley.EDU>
Date: 11 Dec 89 18:26:33 GMT
References: <11383@csli.Stanford.EDU>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jas@postgres.berkeley.edu (James Shankland)
Organization: The Eddie Group
Lines: 23

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