Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!noao!asuvax!mcdphx!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.xenix
Subject: Re: Xenix Shared Memory Limitation
Summary: Certainly NOT true on SV/386 (Xenix)
Message-ID: <3079@ddsw1.MCS.COM>
Date: 7 Mar 89 14:42:24 GMT
References: <189@melpar.UUCP> <141100003@cpe>
Reply-To: karl@ddsw1.UUCP (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 30

In article <141100003@cpe> tif@cpe.UUCP writes:
>
>Written 10:37 am  Feb 23, 1989 by melpar.UUCP!toppin in cpe:comp.unix.xenix
>>We have been assuming that we would allocate 21-65K shared memory 
>>segments and just divide up the records into the segments.
>>...
>>We just tried a simple test and we can allocate the segments with no problem.
>>But, when any process is run at any other terminal
>>while the segments exist only a shell prompt comes back.
>
>Just guessing: I suspect that the shared memory segments are not
>allowed (why?) to leave real memory.  Memory must be real tight
>and the fork is failing.  (Get more memory)

I have to disagree for the situation where the OS is SV/386; I have no
idea what if any restrictions are present in the '286 port.

We have allocated 1M shared segments on SV/386 (Xenix), and that couldn't
have worked if this restriction was "real".

Xenix V/386 2.2.1 had some problems with shared segments (wierd things would
occasionally occur), but the 2.2.3 and 2.3.1 versions work fine...

(We have a game here which allocates about 1MB in shared segments when it
starts up; thus our extensive experience with this :-)

--
Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl)
Data: [+1 312 566-8912], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.    	"Quality solutions at a fair price"