![]() | |||||||||||
Messages in this thread |
Hi. Hugh Dickins wrote: >> I disagree with this. The way I am using it may look horrible, >> but yes, I do use it without the fork(). > Then I think you have no reason to use MAP_SHARED: use MAP_PRIVATE > and you should get the behaviour you require, without kernel change. Hugh, I think you misunderstood me because once again I wrote something, said nothing - happens to me sometimes. The trick is that I am setting the old_len arg of mremap() to 0. This means that the new mapping is created while the old one is *not* being destroyed. So I get multiple virtual memory areas referencing the same shared memory region, lets call them "aliases". You propose to share the same backing-store across the multiple processes. Instead, I am sharing it across the multiple memory areas of a single process. I can't use MAP_PRIVATE for that, really. Then I want to expand my initial pool of shared mem while preserving the already created "aliases", and there seems to be no way of doing that: creating the larger pool and mremap'ing old one to the beginning of the new one, leaves the VMAs unmerged; creating the larger pool and mamcpy() the content of the old one to it, doesn't preserve the already created "aliases". The only thing I can do, is to expand the initial pool with mremap(), which doesn't work. So I have to resort to the more heavyweight things like shm_open(), while otherwise the expandable anonymous shared mapping can suit very well for my needs. > Shared anonymous is peculiar: although mapping is anonymous (nothing > shared with unrelated mms), modifications are shared between parent > and children. It's half-way between anonymous and file-backed. > We agree that it might be nice to let the object used to support that > be extended if mremap extends the mapping. But it might instead just > be needless feature creep. But then I beleive the entire idea of anonymous shared mapping is also a crap. But since it is already there, I would like to have it fully functional, so that I can avoid the things like shm_open() when possible. I just don't see the reason of keeping something partially implemented. > Sorry, your case does not persuade me yet. Well, I beleive perhaps you missed the fact that I was setting the old_len to 0 in mremap(), which doesn't work as I want to, when you use MAP_PRIVATE. You'll probably call it a horrible hack, but here's where that technique comes from: http://www.ussg.iu.edu/hypermail/linux/kernel/0401.1/1351.html And since it comes from here, I beleive it must be fully supported. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-03-22 14:03 [from the cache] ©2003-2008 | |||||||||||