RE: need lots of shared memory (with shmget) in a Cocoa app
RE: need lots of shared memory (with shmget) in a Cocoa app
- Subject: RE: need lots of shared memory (with shmget) in a Cocoa app
- From: Norm Green <email@hidden>
- Date: Fri, 13 Jul 2007 13:13:21 -0700
Title: RE: need lots of shared memory (with shmget) in a Cocoa app
Jay,
I recently ported our Smalltalk virtual machine and application server to Darwin. Like LISP, Smalltalk uses substantial amounts of heap and shared memory. I had no problems getting 10 MB of shared memory after I increased the default limits in /etc/rc and rebooted.
Here is the line in /etc/rc I changed:
sysctl -w kern.sysv.shmmax=104857600 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=104857600
I am on this version of Darwin:
Darwin Kernel Version 8.9.3: Fri Apr 27 14:50:07 PDT 2007; root:xnu-792.19.5~2/RELEASE_I386
I didn't locate any docs on the subject, I just made the changes above and it worked.
Hope this was helpful.
Norm Green
GemStone Systems Inc.
http://www.gemstone.com/smalltalk/
-----Original Message-----
From: Jay Reynolds Freeman [mailto:email@hidden]
Sent: Friday, July 13, 2007 1:03 PM
To: email@hidden list
Subject: need lots of shared memory (with shmget) in a Cocoa app
This topic overlaps Cocoa and Darwin, bear with me a minute:
I would like to make some serious use of interprocess shared memory
in Cocoa applications. I don't mean pipelines or their equivalents;
my project involves having multiple different applications all making
asynchronous reads and writes to different parts of a large (Gigabyte)
area of shared memory. (Details later, for the curious.) I would be
using shmget, shmat, and so on, as low-level primitives to obtain and
access shared memory.
I have figured out that OS X doesn't support that much shared memory
right out of the box. (BTW,I am running 10.4.10 on a 13-inch Intel
Macbook with 1 GByte of physical memory.) I have done enough research
to know that some of the parameters that control shared memory are in
/etc/rc, which is read at boot-time, and I even managed to find some
documentation on the web for what kern.sysv.shm<whatever> means.
(The documentation I found was in Spanish, which I don't read or
speak, but fortunately the Google translation was usable -- the search
experience was sufficiently Monty-Pythonesque that I found myself
lifting my feet in case of killer rabbits.) And I found a lot of
comments from people who had tried to get shared memory to work
on the Mac, and had not been as successful as they had hoped.
I hope that is enough homework to warrant an appeal to this group
for further pointers. Specifically,
1) Is there any thorough documentation anywhere about how
shared memory on the Mac actually works? I need all the
background information I can get, and I certainly need
to know whether there are hard or soft range limits
for the kern.sysv.<whatever> parameters, and what
happens if you crowd those limits. Just man pages
aren't near enough, and googling and searching XCode
documentation hasn't turned up anything interesting yet.
2) What am I likely to break elsewhere in the Mac
architecture if I start increasing shared-memory limits?
3) How do the layers of software architecture upon which
a Cocoa application runs interact with the shared memory
stuff? I haven't tried messing with /etc/rc yet, but
in my application, I could not successfully create
even a 1 MByte shared-memory segment. I suspect that
something else is using enough of the default shared-memory
resources that there weren't enough left for my test, and
I need to know how much to allow for any such uses.
(If this question should go to another group, tell
me and I will take it there.)
If you are still reading and are curious, what I have is a
functioning Lisp system (Wraith Scheme -- see my web site if
you are terminally curious (URL below)); I think I have a way
to add an access-rights system to it such that multiple copies
of the Lisp interpreter can interact with the same heap without
stepping on each others' toes. The heap is the big shared
memory object I spoke of. (Lisps eat memory as if there were no
tomorrow, 1 GByte is not a lot...) Using just separate threads,
one for each Lisp interpreter, isn't appropriate, because each
interpreter has substantial amounts of truly private data. Just fork
(without exec) won't work on a Mac app, at least, not if you want
both parent and child to have a functioning GUI.
Small numbers of cooperating parallel Lisp processes would be fun,
and would be a natural fit to present and likely near-future Mac
processor hardware.
Enough blathering. Thanks for any hints or suggestions you
may have.
-- Jay Reynolds Freeman
---------------------
email@hidden
http://web.mac.com/jay_reynolds_freeman (personal web site)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden