 | | | | |
| TSharedSream — класс упрощающий работу с файлом подкачки |
Полный текст материала
Другие публикации автора: Алексей Румянцев
Цитата или краткий комментарий: | «... Реализует и упрощает процесс создания и работу с файлом подкачки.
Расширяет возможности работы с объектом отображения данных.
Может рассматриваться как альтернатива TFileStream, TMemoryStream. ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 16 | 94.1% | | | | | Ничего особенно нового и интересного | | [2] | 0 | 0% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 1 | 5.9% | |
Всего проголосовали: 17 | | | | Все понятно, материал читается легко | | [1] | 14 | 93.3% | | | | | Есть неясности в изложении | | [2] | 1 | 6.7% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 15 |
[TStream] [TMemoryStream] [TFileStream] [TMemo] [Exception] [Функции для работы с файлами ] [Файл подкачки] [Маппированные файлы]
Отслеживать это обсуждение 
Всего сообщений: 1017-04-2003 14:43Для тех кто использовал TRySharedStream в своих программах:
Имя TRySharedStream было изменено на TRySwapStream имя соответствующего юнита также было изменено с SharedStream на SwapStream, извините за неудобство.
To moniker:
Надо было сделать оговорочку что это не касается TRySwapStream, т.к. он не создает новых файлов. |
|
17-04-2003 14:22| Не пугайтесь большого размера архива, на самом деле он маленький, просто, скорей всего, Экзешник попался или временный файл. Елена удалите его, пожалуйста, из архива. |
|
05-09-2002 16:29
02-10-2001 15:07А вот и свежий прикол на тему file mapping under win98. Функция FlushViewOfFile под win98 реально ничего НЕ делает. Данные кешируются, но на диск в тот же момент не попадают.
РЕШЕНИЕ: Вызвать FlushFileBuffers, передать ей хэндл файла, полученный с помощью CreateFile, тот самый, который использовался в вызове CreateFileMapping.
Да, определенно, на реализации file mapping"a под win98 разработчики Microsoft отдохнули :) |
|
23-09-2001 23:43
23-09-2001 23:34File mapping - один из любимых моих коньков. Поэтому добавлю кое-что от себя :)
Реализация API file mapping кардинально различается для Win9x и WinNT/2000/XP. Впрочем, если автор сказал, что под 95/98 все работает хорошо, это фактически означает, что под NT-системами все будет просто великолепно. Однако это касается только данного конкретного случая, да и то наверняка не все варианты были протестированы.
Наученный самым горьким опытом (продукт, построенный целиком на file mapping"e и писавшийся под Win2000, за несколько дней до выпуска беты фактически перестал работать под Win98), могу сразу дать жизненно важный для работы file mapping"a совет :) Под Win9x всегда нужно создавать именованные объекты проецирования, т.е. в функцию CreateFileMapping передавать непустое (!) имя. Само имя не важно, можно его генерировать случайным образом, важен сам факт его присутствия. При этом работа ядра с именованными и неименованными объектами осуществляется совершенно по разному (какой синюга это писал, можно только догадываться :)
Алексей предлагает делать такой поток на основе файла подкачки. При этом для изменения размера объекта проецирования без потери данных приходится полностью их дублировать. При больших размерах потока это может быть накладно. Как вариант, можно создавать проецирование на основе временного файла, а не на основе памяти (т.е. файла подкачки). По сути этот временный файл будет мало чем отличаться от файла подкачки системы. При этом при пересоздании объекта проецирования с новым размером нам не нужно копировать данные, они останутся в файле. Мы экономим память в два раза.
Кто-то скажет, что такой вариант будет значительно медленнее за счет дисковых операций. Это вопрос очень тонкий и вот что на него может повлиять:
1. За счет кеширования дисковых операций вероятность того, что данные будут немедленно сброшены на диск при пересоздании проецирования весьма мала. Скорее всего, этот процесс пройдет как обычная операция с памятью.
2. При значительных размерах потока даже первоначальный вариант может требовать своппинга страниц в/из файла подкачки.
3. Создание второго объекта проецирования такого же размера с большой вероятностью приведет к свопингу страниц памяти системы в файл подкачки с целью освободить физическую память для нового объекта. А это уже очень длительный процесс.
Как видим, вариант на основе временного файла может оказаться даже быстрее :) Это конечно сильно зависит от условий применения. Для такого потока также была бы очень полезной возможность проецировать не весь объект сразу, а лишь окно определенного размера (MapViewOfFile), что значительно снизило бы потребности в памяти.
Вообще же file mapping - очень интересная технология. У нее есть масса самых разнообразных применений. Особенно рекомендую ее тем, кто всерьез работает с файлами или кому необходим высокоскоростной обмен данными между процессами.Сообщение не подписано |
|
11-09-2001 15:24Вообщем-то то, что M$ ввела саму возможность ошибки - показывается, что такая ситуация возможна (вы сами это признаете, т.к. обработку этой ошибки делаете... ;-). Что касается конкректного случая, то если я правильно думаю и ошибка там возникает из-за невозможности выделить регион виртуальных адресов, то 500 Мб маловато... Я вечером глчну в рихтора, скажу точнее, возможно попробую реализовать что бы ошибка возникала именно здесь.
Кроме того - передача nil в UnmapViewOfFile возможна после exception при создании объекта отображения - раз конструктор не отработал будет вызван деструктор, а там и UnmapViewOfFile стоит. |
|
10-09-2001 15:35Уважаемый Дмитрий.
Если Вас не затруднит поясните, пожалуйста, следующий момент :
>1) в методе Create, строка:
>FMemory := MapViewOfFile(SHandle, FILE_MAP_WRITE, 0, 0, Sz);
>вообзем-то понятно, что может произойти ощибка, например нехватит
>виртуальных адресов, если попытка выделить слишком большой кусок,
>а программа как раз всю память сразу делает отображенной.
Покажите, пожалуйста, пример возникновения этой ошибки. Я даже не видел ни разу развития такой ситуации.
Я выделял 100, 500M, но все было без ошибок. |
|
10-09-2001 11:58Как минимум имеется два ляпа, в принципе не приводящих к фатальным последствиям, но...
1) в методе Create, строка:
FMemory := MapViewOfFile(SHandle, FILE_MAP_WRITE, 0, 0, Sz);
вообзем-то понятно, что может произойти ощибка, например нехватит виртуальных адресов, если попытка выделить слишком большой кусок, а программа как раз всю память сразу делает отображенной. В случае ошибки вызывается исключение, при этом дальнейший код не выполняется, а именно строка:
CloseHandle(SHandle); - т.е. происходит утечка ресурсов, хоть и до конца жизни процесса.
2) Второй ляп вытекает из первого - если создать TSharedStream не удалось, то вызывается деструктор со строкой:
UnmapViewOfFile(FMemory); при этом, если события разворачивались по последнему сценарию или exception произошел раниьше, при создании объекта отображения, то FMemoty будет = nil, к exception это не приведет, но все таки такое оставлять не стоит...
|
|
07-09-2001 16:48| Могу предложить свой вариант TSharedSream. Как мне кажется, более функциональный. |
|
|
|
