Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!eliot!reidc From: reidc@eliot.UUCP (Reid Carson/Development) Newsgroups: comp.lang.c Subject: Re: shared memory Keywords: shared memory Message-ID: <556@eliot.UUCP> Date: 26 Sep 90 18:06:12 GMT References: <566@gestetner.oz> Sender: root@eliot.UUCP Reply-To: reidc@eliot.UUCP (Reid Carson/Development) Organization: UNITECH Software, Inc., Reston, VA Lines: 29 Let me just add a few observations about shared memory, from our experiences in porting to a number of different systems. It's generally easiest to let the point of attachment be selected by the system, unless you have some reason to do otherwise. Unfortunately, one such reason is that if you need to malloc more than 20 or 30K after attaching the shared memory, the malloc may fail, since the address at which the segment gets mapped effectively limits your process's maximum break point (and can also limit the size of your stack). This varies from system to system. Under SunOS, the segment maps quite high in your address space, so there's no problem. Under Ultrix 3.0 (on our system, anyway), the segment is mapped about 33K above the current break point, which is fine unless you need to malloc more than that, or your stack gets pretty big, both of which are true for us. Our solution is to run a small test program in our Configure script when starting the port. The test program attaches a segment, checks the address it maps at, and defines a symbol in the generated config.h to indicate whether a shared memory segment maps sufficiently high or not. Thus the real program can know whether to let the segment map at the default address, or attach it up near the maximum break value. I should also mention that if you need to select the address yourself, you should put the shmat() in a loop, decrementing the address each time through, since some systems have limitations on how high you may attach a segment. You may need to decrease the address by several million on a system like a Silicon Graphics (if my memory serves me correctly).