9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Geoff Collyer <geoff@collyer.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] shared memory
Date: Fri, 12 Sep 2003 02:25:48 -0700	[thread overview]
Message-ID: <60c7fdf45121206846fb9f34f2588b77@collyer.net> (raw)
In-Reply-To: <b7dbb55d564e34d09fe59ddea98ca20d@granite.cias.osakafu-u.ac.jp>

I wouldn't have called shmat `user friendly' and I don't think it's
any easier to use than the Plan 9 machinery.  shmat, shmget, etc.
don't really do much for you; they just do what segattach does, but in
a more complicated way.  You still have to arrange to coordinate
access by the processes sharing the memory.  I think

	char *ss = (char *)segattach(0, "shared", nil, length);

is all you need to allocate a shared segment of size `length', though
you still have to actually share it, probably by forking.

If the processes in question are related, you don't even need
segattach, just be careful to keep per-process data on the stack (in
automatic variables) and when you rfork(), be sure to include the
RFMEM flag.  After the rfork, parent and child will share their data
segment.

If you're looking for a way for unrelated processes to share memory, I
think your best bet is to use the undocumented S option of ramfs:

	ramfs -S shared1

to create a sharable /tmp, then have all the programs that want to
share the memory do:

	mkdir /tmp/shared1
	mount -c /srv/shared1 /tmp/shared1

The 'l' permission bit on files in /tmp/shared1 can implement locks.

How are you trying to share memory (or what are you trying to
accomplish)?  All of the above assumes that you want something like
System V shared memory.



  reply	other threads:[~2003-09-12  9:25 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-12  5:32 [9fans] g++ YAMANASHI Takeshi
2003-09-12  7:25 ` okamoto
2003-09-12  9:29 ` northern snowfall
2003-09-12  8:33   ` okamoto
2003-09-12  8:43     ` [9fans] shared memory okamoto
2003-09-12  8:48       ` Geoff Collyer
2003-09-12  8:52         ` okamoto
2003-09-12  9:25           ` Geoff Collyer [this message]
2003-09-12  9:30             ` Charles Forsyth
2003-09-12 15:33               ` splite
2003-09-12 16:11             ` boyd, rounin
2003-09-12 12:12           ` David Presotto
2003-09-16  3:07             ` okamoto
2003-09-15 13:30               ` okamoto
2003-09-16  4:23               ` Russ Cox
  -- strict thread matches above, loose matches on Subject: below --
2002-07-29 11:13 paurea
2002-07-29 13:56 ` Ronald G Minnich
2002-07-29 13:59   ` Ronald G Minnich
2002-07-31 12:52 ` andrey mirtchovski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60c7fdf45121206846fb9f34f2588b77@collyer.net \
    --to=geoff@collyer.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).