LINUX.ORG.RU

Увеличение размера замапленой shm на лету

 ,


0

1

Стандартная последовательность работы с shm

  • shm_open
  • ftruncate
  • mmap

Несколько вопросов:
1. Почему я могу работать с данными за пределами замапленного размера и ничего не падает? По идее SIGBUS должен был случиться. Valgrind тоже ничего подозрительного в этом не заметил. Предполагаю, что shm_open создает объект размером со страницу, например. И поэтому все «хорошо», пока я за этот размер не вылезу.

2. Что реально делает ftruncate? Изменяет размер shm объекта, или только размер файла в /dev/shm? Я провел несколько экспериментов - судя по всему, второе.

3. Если описаное в пункте 1 не нормально, т.е. SIGBUS может выстрелить в самый неожиданный момент, то можно ли как-то перемапить с другим размером? Я вижу два варианта: замапить на тот же адресс, но с большим размером(MAP_FIXED вроде как заставляет использовать переданный адресс) ИЛИ выделять безумно большой размер, например, с оперативу, и надеятся что больше не понадобится, а если и понадобится, то нужно добавить оперативки, ибо все равно работать не будет.

★★

shm_open создает объект размером со страницу, например.

mmap мапит по страницам, вот про это: http://lwn.net/Articles/357767/

ftruncate изменяет размер файла, а не замапленной области.

Не знаю относительно MAP_FIXED, но если вы после одного mmap сделали mmap другого файла и получили от второго указатель «за» первым, то особо первую mmap область не увеличишь, она «упрётся» во второй указатель, поэтому в общем случае нужно увеличивать размер файла и делать новый mmap.

Ну или mremap, но быть готовым, что будет новый указатель и нужно использовать его, а не старый.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Спасибо, почему-то я mremap проглядел в документации...

Т.е. нужно спроектировать приложение так, чтобы нигде не хранить указатели на замапленную память и все будет ок.

kulti ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.