scott@erick.gac.edu (Scott Hess) (02/21/91)
In article <1991Feb21.152540.10679@noose.ecn.purdue.edu> songer@orchestra.ecn.purdue.edu (Christopher M Songer) writes:
I'm looking to port a SysV piece of code. The code uses
shared memory extensively. Can memory be shared between processes
on the NeXT, and if so, how? I RTFM and it seemed to imply that
memory can only be shared when there is a parent - child
relationship between processes. This is not good enough.
Nowhere, however, did it say: "Memory cannot be shared between
arbitrary processes on the NeXT computer." So, I figured I'd ask
before scrapping whole boatloads of code.
Any task with access ability >= to the task in question can share that
task's memory, no questions asked. For instance, two tasks running
with "scott" access will be able to play with each other's memory.
Of course, you'd generally not want to do that :-). Anyhow, the
documentation is in /NextLibrary/Documentation/NextDev/OSSoftware/01_Mach
for NextStep2.0, and a similar place for 1.0.
Basically, you can get the task of a process from the pid, and you can
share memory with a process by knowing it's task, and then mapping the
memory into your own space. It looks to be fairly simple, though I've
not tested it too much, yet (I've not that much use for it at this
time, either).
Later,
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once. Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."songer@orchestra.ecn.purdue.edu (Christopher M Songer) (02/21/91)
Hi,
I'm looking to port a SysV piece of code. The code uses
shared memory extensively. Can memory be shared between processes
on the NeXT, and if so, how? I RTFM and it seemed to imply that
memory can only be shared when there is a parent - child
relationship between processes. This is not good enough.
Nowhere, however, did it say: "Memory cannot be shared between
arbitrary processes on the NeXT computer." So, I figured I'd ask
before scrapping whole boatloads of code.
Other questions: is a mutex the best equivalent of a semaphore
in SysV? Assuming there is no shared memory, what would you reccomend
as a method to emulate or replace it?
Thanks!
-Chris
robertl@bucsf.bu.edu (Robert La Ferla) (02/22/91)
Use vm_allocate() to allocate shared memory. This should be documented on-line but if it isn't, you should read up on the MACH operating system. Robert La Ferla Lotus Development Corporation robertl@bucsf.bu.edu "Improv-ising in the NeXT dimension!"
briand@rfengr.com (Brian Dear) (02/22/91)
Good to hear I'm not the only one who needs shared memory on the NeXT. I too need shmget(), shmat(), shmdt(), etc BADLY for some code I'm porting to the NeXT environment. Anti-AT&T System V UNIX gurus may scoff, but the System V shared memory routines have been a joy to use and are, above all, _simple_ to implement. I haven't figured out an alternative yet for NeXT. If Mach's so great, how come it's so difficult to implement a simple shared memory setup like you can do in UNIX System V? Any suggestions from knowledgeable Mach programmers would be *greatly* appreciated. It would be ideal if a publicly-available set of routines were available that either mimicked or emulated the System V shared memory routines. I'd even be interested to hear about commercially-available routines that can be used on the NeXT to do this. -- brian Brian Dear brian@coconut.com Coconut Computing, Inc.
michael@hapuna.cs.ucla.edu (michael gersten) (03/09/91)
My understanding of Mach (not necessarily NeXT OS) was that an external pager could be written (and was written at CMU) to allow two unrelated tasks to share memory. If this program would work on the NeXT, you should be able to grab it, port an interface to look identical to the system 5 code, and presto!. I'd be interested in it also. Michael
edwardj@microsoft.UUCP (Edward JUNG) (03/12/91)
In article <michael.668476436@hapuna> michael@hapuna.cs.ucla.edu (michael gersten) writes: > >My understanding of Mach (not necessarily NeXT OS) was that an external pager >could be written (and was written at CMU) to allow two unrelated tasks to >share memory. If this program would work on the NeXT, you should be able to >grab it, port an interface to look identical to the system 5 code, and presto!. Last I checked, the external pager interface was not enabled in the NeXT version of Mach (largely for performance reasons, I expect). I have not checked for this in the 2.0 release. Perhaps Morris Meyer could update the newsgroup? -- Edward Jung Microsoft Corp. My opinions do not reflect any policy of my employer.
songer@orchestra.ecn.purdue.edu (Christopher M Songer) (03/13/91)
Being one of the people that started this thread, I'd just like
to comment that I have seen NO evidence to support the existence
of external pager support in Next OS of any version 1.0 or later.
An nm on the kernel shows the absence of several crucial calls.
Additionally, the nasty silence I have had out of ask_next doesn't
inspire hope. In reality, there seems to be only one call that will
even give you a memory object back, and this is certainly not an
allocation call, mearly an inquiry (vm_region).
As a result, I've pretty much given up on doing a sysV shared
memory / IPC emulation library until a new OS version comes out. I
suppose I'll look again at feasibility then.
I too have heard there were performance problems with Mach2.5's
external pager support, so maybe the absence is not a bad thing.
Still, sysV IPC compatibility would be nice from a user standpoint
(if not a purist standpoint) and I do hope support for some sort of
kernel service that would allow sysV shared memory emulation (maybe
non-copy on write files....) will come out in future releases.
-Chrispaul@zaphod.uchicago.edu (Paul Burchard) (03/14/91)
In article <1991Mar12.170806.4691@noose.ecn.purdue.edu> songer@orchestra.ecn.purdue.edu (Christopher M Songer) writes: > >Still, sysV IPC compatibility would be nice from a user standpoint >(if not a purist standpoint) and I do hope support for some sort of >kernel service that would allow sysV shared memory emulation (maybe >non-copy on write files....) will come out in future releases. > >-Chris One example: Berkeley's large, free POSTGRES relational database management system uses shared memory extensively. I doubt anyone would volunteer to convert the 100,000+ lines of code to make use of Mach IPC---so this is a lost opportunity for NeXT'ers. (Actually, they use so much shared memory that kernel modification is part of their standard installation procedure, even for SysV-compatible systems!) On the other hand, seeing as I fit the NeXT Perfect Customer Personality Profile :-), when the two are really in conflict, I and my wallet will gladly take the side of ``innovation'' over ``compatibility''. ----------------------------------------------------------------------------- Paul Burchard <burchard@math.utah.edu> ``I'm still trying to learn how to count backwards from infinity...'' -----------------------------------------------------------------------------