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
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
Hugh Dickins wrote:
On Mon, 9 Jul 2007, William Tambe wrote:
Hugh Dickins wrote:
I've come right around to your original view, Stas, and William's:
if that mmap creates such an object, then the expanding mremap really
ought to be useful, and allow the underlying object to be expanded.
The sha
On Mon, 9 Jul 2007, William Tambe wrote:
> Hugh Dickins wrote:
> >
> > I've come right around to your original view, Stas, and William's:
> > if that mmap creates such an object, then the expanding mremap really
> > ought to be useful, and allow the underlying object to be expanded.
> > The shared
Hugh Dickins wrote:
On Mon, 2 Jul 2007, Stas Sergeev wrote:
Hugh Dickins wrote:
You've answered your own question: we did not make the change Stas
suggested, IIRC because I remained a little uneasy with that change
in behaviour, and nobody else spoke up for it.
IIRC your argument, that made s
Hi.
Hugh Dickins wrote:
You were gracious enough to accept my arguments back then, but after
mulling this over overnight, I've come to think I was just too timid
back then, and gave too much weight to the issue of there being no
shrink, and to the issue that child might expand the object without
On Mon, 2 Jul 2007, Stas Sergeev wrote:
> Hugh Dickins wrote:
> > You've answered your own question: we did not make the change Stas
> > suggested, IIRC because I remained a little uneasy with that change
> > in behaviour, and nobody else spoke up for it.
> IIRC your argument, that made sense to me
Hello.
William Tambe wrote:
And it just doesn't make sens to have mmap() map ANONYMOUS shared memory
and mremap() not to expand it and make the expanded area available.
I agree with this, but the argument against
that approach was that then you can only
enlarge the backing-store, but never shri
Hi.
Hugh Dickins wrote:
You've answered your own question: we did not make the change Stas
suggested, IIRC because I remained a little uneasy with that change
in behaviour, and nobody else spoke up for it.
IIRC your argument, that made sense to me,
was that with such an approach, you can only
e
Yes, I have a good case, but my case may not sound interesting until you
see it working.
Ok, I am developing a dynamic memory allocation routine which takes
direct advantage of the ability of a machine to use Virtual Memory to
make everything look contiguous and fast.
And it just doesn't mak
On Fri, 29 Jun 2007, William Tambe wrote:
> I read a post that you made about not being able to expand anonymous shared
> mapping with mremap(). And I am actually having that issue now.
I guess you're referring to the thread at
http://lkml.org/lkml/2004/6/16/155
and you're asking either Stas or m
I read a post that you made about not being able to expand anonymous
shared mapping with mremap(). And I am actually having that issue now.
You made the post in 2004 and we are now in 2007. I would like to know
if that feature was added because the code below always fail with bus
error on my m
12 matches
Mail list logo
