Сообщение Re[2]: VirtualAlloc и MapViewOfFile от 17.02.2018 5:41
Изменено 17.02.2018 6:07 Alexander G
Re[2]: VirtualAlloc и MapViewOfFile
Здравствуйте, Poseidon, Вы писали:
P>Здравствуйте, Poseidon, Вы писали:
P>>Здравствуйте! Не секрет что mapviewoffile терпит неудачу при работе с достаточно большим по размеру файлом.
P>>Вопрос — можно ли это вылечить если сначала вызвать CreateFileMapping или MapViewOfFile с флагом MEM_RESERVE?
P>>Для достаточно большой области памяти.
P>>А потом узнать объем памяти которую можно закомитить (кстати какой функцией это можно сделать?)
P>>Заключить код работы с памятью в SEH и при возникновении ошибки доступа к памяти вызывать MapViewOfFile
P>>повторно с указанием флага MEM_COMMIT и размера блока который система способна выделить?
P>>делал нечто подобное с VirtualAlloc, а теперь хочу разобраться как это можно сделать для образа файла.
P>непонятно вот что в работе маппинга
P>CreateFileMapping ... nSizeMax) — выделяет мне область памяти с МАКСИМАЛЬНЫМ размером который мне нужен
P>MapViewOfFile(Ex) — можно по частям, предварительно вызвав UnmapViewOfFile
P>А что происходит с выделенной областью памяти?? Она мне непрерывная нужна! Где гарантия что MapView по частям спроецирует
P>адрес именно в нужное место?
Зачем такая гарантия нужна? Пусть проецирует, куда получается.
При указании смещения в параметре MapViewOfFile будет спроецирована именно та часть маппинга, которая соответствует этому смещению.
Таким образом, куски MapViewOfFile "рваные", но их базовый CreateFileMapping остаётся непрерывным.
P>Может быть выделить область для маппинга размером допустим 100 мб,
P>большую непрерывную область выделить функцией VirtualAlloc и использовать AWE для обмена данными между маппингом и основной памятью?
Маппинги AWE всё равно проецируются куда попало, как и MapViewOfFile, и точно так же достаточно большой AWE не будет проецироваться одним куском.
AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
P>А потом сбросить всю память на диск функцией WriteFile?
WriteFile всё равно не сможет записать файл одним большим куском, у него ограничение 64 мегабайта, её придётся в цикле вызывать.
Какая тогда разница, один кусок в гигабайт, или десять по мегабайту.
P>Здравствуйте, Poseidon, Вы писали:
P>>Здравствуйте! Не секрет что mapviewoffile терпит неудачу при работе с достаточно большим по размеру файлом.
P>>Вопрос — можно ли это вылечить если сначала вызвать CreateFileMapping или MapViewOfFile с флагом MEM_RESERVE?
P>>Для достаточно большой области памяти.
P>>А потом узнать объем памяти которую можно закомитить (кстати какой функцией это можно сделать?)
P>>Заключить код работы с памятью в SEH и при возникновении ошибки доступа к памяти вызывать MapViewOfFile
P>>повторно с указанием флага MEM_COMMIT и размера блока который система способна выделить?
P>>делал нечто подобное с VirtualAlloc, а теперь хочу разобраться как это можно сделать для образа файла.
P>непонятно вот что в работе маппинга
P>CreateFileMapping ... nSizeMax) — выделяет мне область памяти с МАКСИМАЛЬНЫМ размером который мне нужен
P>MapViewOfFile(Ex) — можно по частям, предварительно вызвав UnmapViewOfFile
P>А что происходит с выделенной областью памяти?? Она мне непрерывная нужна! Где гарантия что MapView по частям спроецирует
P>адрес именно в нужное место?
Зачем такая гарантия нужна? Пусть проецирует, куда получается.
При указании смещения в параметре MapViewOfFile будет спроецирована именно та часть маппинга, которая соответствует этому смещению.
Таким образом, куски MapViewOfFile "рваные", но их базовый CreateFileMapping остаётся непрерывным.
P>Может быть выделить область для маппинга размером допустим 100 мб,
P>большую непрерывную область выделить функцией VirtualAlloc и использовать AWE для обмена данными между маппингом и основной памятью?
Маппинги AWE всё равно проецируются куда попало, как и MapViewOfFile, и точно так же достаточно большой AWE не будет проецироваться одним куском.
AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
P>А потом сбросить всю память на диск функцией WriteFile?
WriteFile всё равно не сможет записать файл одним большим куском, у него ограничение 64 мегабайта, её придётся в цикле вызывать.
Какая тогда разница, один кусок в гигабайт, или десять по мегабайту.
Re[2]: VirtualAlloc и MapViewOfFile
Здравствуйте, Poseidon, Вы писали:
P>Здравствуйте, Poseidon, Вы писали:
P>>Здравствуйте! Не секрет что mapviewoffile терпит неудачу при работе с достаточно большим по размеру файлом.
P>>Вопрос — можно ли это вылечить если сначала вызвать CreateFileMapping или MapViewOfFile с флагом MEM_RESERVE?
P>>Для достаточно большой области памяти.
P>>А потом узнать объем памяти которую можно закомитить (кстати какой функцией это можно сделать?)
P>>Заключить код работы с памятью в SEH и при возникновении ошибки доступа к памяти вызывать MapViewOfFile
P>>повторно с указанием флага MEM_COMMIT и размера блока который система способна выделить?
P>>делал нечто подобное с VirtualAlloc, а теперь хочу разобраться как это можно сделать для образа файла.
P>непонятно вот что в работе маппинга
P>CreateFileMapping ... nSizeMax) — выделяет мне область памяти с МАКСИМАЛЬНЫМ размером который мне нужен
P>MapViewOfFile(Ex) — можно по частям, предварительно вызвав UnmapViewOfFile
P>А что происходит с выделенной областью памяти?? Она мне непрерывная нужна! Где гарантия что MapView по частям спроецирует
P>адрес именно в нужное место?
Зачем такая гарантия нужна? Пусть проецирует, куда получается.
При указании смещения в параметре MapViewOfFile будет спроецирована именно та часть маппинга, которая соответствует этому смещению.
Таким образом, куски MapViewOfFile "рваные", но их базовый CreateFileMapping остаётся непрерывным.
P>Может быть выделить область для маппинга размером допустим 100 мб,
P>большую непрерывную область выделить функцией VirtualAlloc и использовать AWE для обмена данными между маппингом и основной памятью?
Маппинги AWE всё равно проецируются куда попало, как и MapViewOfFile, и точно так же достаточно большой AWE не будет проецироваться одним куском.
AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.
P>Здравствуйте, Poseidon, Вы писали:
P>>Здравствуйте! Не секрет что mapviewoffile терпит неудачу при работе с достаточно большим по размеру файлом.
P>>Вопрос — можно ли это вылечить если сначала вызвать CreateFileMapping или MapViewOfFile с флагом MEM_RESERVE?
P>>Для достаточно большой области памяти.
P>>А потом узнать объем памяти которую можно закомитить (кстати какой функцией это можно сделать?)
P>>Заключить код работы с памятью в SEH и при возникновении ошибки доступа к памяти вызывать MapViewOfFile
P>>повторно с указанием флага MEM_COMMIT и размера блока который система способна выделить?
P>>делал нечто подобное с VirtualAlloc, а теперь хочу разобраться как это можно сделать для образа файла.
P>непонятно вот что в работе маппинга
P>CreateFileMapping ... nSizeMax) — выделяет мне область памяти с МАКСИМАЛЬНЫМ размером который мне нужен
P>MapViewOfFile(Ex) — можно по частям, предварительно вызвав UnmapViewOfFile
P>А что происходит с выделенной областью памяти?? Она мне непрерывная нужна! Где гарантия что MapView по частям спроецирует
P>адрес именно в нужное место?
Зачем такая гарантия нужна? Пусть проецирует, куда получается.
При указании смещения в параметре MapViewOfFile будет спроецирована именно та часть маппинга, которая соответствует этому смещению.
Таким образом, куски MapViewOfFile "рваные", но их базовый CreateFileMapping остаётся непрерывным.
P>Может быть выделить область для маппинга размером допустим 100 мб,
P>большую непрерывную область выделить функцией VirtualAlloc и использовать AWE для обмена данными между маппингом и основной памятью?
Маппинги AWE всё равно проецируются куда попало, как и MapViewOfFile, и точно так же достаточно большой AWE не будет проецироваться одним куском.
AWE вообще не для этого, а чтобы получить доступ к большому объёму физической памяти.
С учётом того, что x86 версии Windows всё равно ограничены 4 ГБ физической памяти,
а на х64 можно получить её куда более простым способом, собрав 64-битное приложение, AWE сейчас вообще ни для чего не нужно.