All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Tambe <tambewilliam@gmail.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Hugh Dickins <hugh@veritas.com>,
	"Rohland, Hans-Christoph" <hans-christoph.rohland@sap.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Concerning a post that you made about expandable anonymous shared mappings
Date: Thu, 12 Jul 2007 01:35:52 -0500	[thread overview]
Message-ID: <4695CBC8.20508@gmail.com> (raw)
In-Reply-To: <46945895.6070004@aknet.ru>



Stas Sergeev wrote:
> Hi.
> 
> William Tambe wrote:
>> I understand your concern. But since I am working on a dynamic memory 
>> management code that I wish to use with other projects that I have, I 
>> didn't find appropriate to use shm_open.
> Could you please provide a detailed list of the
> problems you have with shm_open? If they are
> valid, then I can bet the patch will be applied,
> no matter what. :)
> 
>> In fact there is a name associated with the shared memory requested 
>> with shm_open, so that it can be mmap(ed) in another process. And I do 
>> not wish to have it accessible by any other process, unless I choose 
>> to do so.
> In this case you need to use shm_unlink() right
> after shm_open(). Then this shm will be accessable
> only to your process and its children, via an fd,
> and not to anyone else. And you still can do anything
> with it (ftruncate/mmap/mremap whatever).
> 

Ok, now I find myself without any other arguments :-) shm_unlink() right 
after shm_open() is a solution.


>> And I think remap(ing) ANONYMOUS memory kind of make a lot of things 
>> easier.
> In what way, exactly?
> 
> 

I wrote the above not knowing that I could use shm_unlink() right after 
shm_open(). But still, I have lost a considerable amount of time trying 
to figure that out.
It appeared all natural to me that I could just remap ANONYMOUS and get 
what I wanted. And the worst thing here is that the man pages do not let 
you know about that.

Sincerely,
William Tambe

      reply	other threads:[~2007-07-12  6:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 19:52 Concerning a post that you made about expandable anonymous shared mappings William Tambe
2007-07-02 15:33 ` Hugh Dickins
2007-07-02 17:35   ` William Tambe
2007-07-02 18:21     ` Stas Sergeev
2007-07-02 18:10   ` Stas Sergeev
2007-07-03 15:48     ` Hugh Dickins
2007-07-03 18:29       ` Stas Sergeev
2007-07-10  1:50       ` William Tambe
2007-07-10 20:10         ` Hugh Dickins
2007-07-10 20:55           ` William Tambe
2007-07-11  4:12             ` Stas Sergeev
2007-07-12  6:35               ` William Tambe [this message]

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=4695CBC8.20508@gmail.com \
    --to=tambewilliam@gmail.com \
    --cc=hans-christoph.rohland@sap.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp@aknet.ru \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.