LINUX.ORG.RU

malloc и файлы.


0

0

Вот вопрос такой возник. Я во многих программах, чтобы обработать ыайл делаю маллок на весь размер файла, потом считываю весь файл целиком и обрабатываю. Но вот что то я задумался, на сколько это эффективно? И очень большой файл получается не обработается? Если я прав, и это не хороший подход, то как поступать в ситуации, когда можно обработать файл только целиком в буфере, например при шифровании и по некоторыми причинам надо шифровать весь файл сразу.

★★★★

А почему не делаешь mmap?

anonymous
()

И потому что файл иногда приходит из сети и его тут же надо обработать. Вот я его и принимаю в маллоченный буфер.

OxiD ★★★★
() автор топика

Всем огромное спасибо, я понял свою ошибку (почитал побольше про mmap).

OxiD ★★★★
() автор топика

Теперь друга проблема. С помощью mmap можно только отобразить изначальный файл. Увеличить его размер не получается. Что делать?

OxiD ★★★★
() автор топика

Я когда-то делал типа своего менеджера памяти через mmap.
Память выделялась в примапленном файле.
так вот для изменения размера приходилось отмапливать, изменять размер, затем опять примапливать :)
Я тогда другого решения не нашел.

Dead ★★★★
()
Ответ на: комментарий от NikZ

Очень неэффективно тратится память (анонимные странички при поджатии страничного кэша должны быть сброшены в pagefile, в то же время как при mmap они просто удаляются из rss), слишком медленно - много копирований между page cache и user-space буферами, т.е. грубо говоря создается над page cache лишняя кэширующая прослойка.

Murr ★★
()
Ответ на: комментарий от NikZ

лишнего копирования между pagecache и user-space буферами наоборот пытаются избегать - так появился системный интрефейс sendfile, например.

Murr ★★
()

Но все равно проблема-то моя осталась. Проблема-то была в поиске ф-ции и без риска того, что памяти не хватит на большой файл (больше ОЗУ и свопа вместе взятых), напирмер, чтобы в памяти держалась небольшпая часть файла, а остальное подкачивалось по мере надобости. Это можно легко сделать с помощью mmap, но мне нужно обеспечить связь с одной кривой библиотекой, которая хочет чтобы файл был целиком в буфере... И доступа к исходникам нету... И самому реализовать нельзя, не позволяют 8-(

OxiD ★★★★
() автор топика
Ответ на: комментарий от OxiD

Походу больше чем ОЗУ+pagefile нереально держать. VM на это не рассчитана. Можно попробовать сделать так: найти внутри своей VM большой непрерывный кусок памяти, который никем не используется (либо через тупой обход VM либо через /proc/self/map) и проимитировать над ним работу VM.

Сделать это можно так: завести небольшой буфер резидентных страничек, например 10-20 штук и объявить, что файл отображен на неразмеченную область VM. Если кто-то полезет в эту область, то ты сразу получишь SIGSEGV, тогда ты можешь удалить одну страничку из RSS и отобразить на fail address страничку, вернув управление на код, который вызвал SIGSEGV.

Единственное что я не вижу как сделать в этой схеме - это как определить в обработчике сигнала где произошла ошибка :(

Murr ★★
()

Хотя я, наверное, не совсем точно ответил на вопрос. Если ты отображаешь реальный файл с помощью mmap, то ему все равно какой у тебя объем памяти и pagefile. Не всё равно, если ты пытаешься выделить память (вроде brk или MAP_PRIVATE), в этом случае можно извращаться как я написал выше.

Где произошла ошибка в этой схеме можно определить, установив SA_RESTORER для данного сигнала и вытащив нужные данные из sigframe.

Всё, IMHO, ессно.

Murr ★★
()

На самом деле не нужен адрес возврата - просто перехватывый SIGSEGV, после обработки сигнала ядро вернет управление на точку, где произошел доступ к памяти.

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