![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TerminateProcess
Суслик © (2005-04-25 14:53:00)Добрый день.
Есть такой псевдокод:
... запись в файл 200 мб из памяти
sleep(500);
TerminateProcess(GetCurrentProcess);
Вопрос: почему система ждет, когда файл запишется и только потом приложение закрывается? Вернее, почему файл оказывается записанным?
ЗЫ. win2000 server, диски ntfs и fat32.
mgcr (2005-04-25 17:04:00) [121]alpet © (25.04.05 16:33) [14]
> Но основной принцип - отложенная запись. На что его можно
> изменить?
Основной принцип - диспетчер кеша не управляет записью. Более того, он даже не знает, какие данные из файлов присутствуют в памяти. Этим всем управляет диспетчер памяти.
Суслик (2005-04-25 16:55:00) [122]
> [11] mgcr © (25.04.05 16:18)
Как раз это противоречит твоим словам...
При close handle никто не сбрасывает кэш.
alpet (2005-04-25 16:33:00) [123]2 mgcr
Особенно жду. Посылка скоро будет доставлена. Но основной принцип - отложенная запись. На что его можно изменить? Конечно кэширование стало более интеллектуальным, и размер системного кэша теперь изменяется системой realtime. Но как это на высокоуровневой доступ к файлам может повлиять ?
mgcr (2005-04-25 16:28:00) [124]
> насколько понимаю принципы кэширования с тех времен не сильно
> изменились
Вообще-то сильно. Советую изучить Руссиновича с Соломоном.
alpet (2005-04-25 16:26:00) [125]> [8] alpet © (25.04.05 16:04)
очень полезная информация.
Разреши поинтересоваться где ты ее взял?
Я в давние времена изучал работу DOS утилиты smartdrv.exe, и насколько понимаю принципы кэширования с тех времен не сильно изменились. Что касается отработки в твоем случае, поток и в самом деле должен умереть практически сразу, засекай время ожидания WaitForSingleObject. Ведь Windows на самом деле нужно АП процесса, которое никуда не девается после завершении "не последнего" потока.
alpet (2005-04-25 16:18:00) [126]По словам Рихтера функция TerminateThread - ассинхронная. Так что надеятся на мгновенную смерть потока не стоит. В любом случае стоит почитать оригинал.
Можешь поэкспериментировать с более жестким завершением потока - уничтожением процесса являющимся отладчиком по отношению к исходниму процессу.
В моей практике были случаи когда время завершения потока
доходило до нескольких минут. Но это было следствием странного зависания потока.
mgcr (2005-04-25 16:18:00) [127]
> the caching algorithm determines when the buffer is written.
Вот тебе все и сказали.
Суслик (2005-04-25 16:12:00) [128]
> [8] alpet © (25.04.05 16:04)
очень полезная информация.
Разреши поинтересоваться где ты ее взял?
alpet (2005-04-25 16:04:00) [129]Твой процесс держит система не до тех пор "пока запишется файл", а до тех пор пока не осуществится копирование заказанного блока памяти в системный кэш. С учетом того что кэш (при ограниченном объеме оперативной памяти) не безразмерный, система вынуждена записывать его на диск. В этом случае файл частично будет записан и частично останется в кэше к моменту закрытия процесса.
Суслик (2005-04-25 15:57:00) [130]
> закрытие такого Handle требует сброса кэша. Пока он сбрасывается,
> Close тебя не отпускает.
тогда как это соотносится с?
If there is data in the internal buffer when the file is closed, the operating system does not automatically write the contents of the buffer to the disk before closing the file. If the application does not force the operating system to write the buffer to disk before closing the file, the caching algorithm determines when the buffer is written.
источник http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_management_functions.asp
Кто-все таки процесс держит?
mgcr (2005-04-25 15:46:00) [131]Суслик © (25.04.05 15:28) [5]
> Но я не понимаю, если я (процесс) закрыл handle у файла,
> почему меня (процесс) кто-то "держит".
Пока Handle не закроется. А закрытие такого Handle требует сброса кэша. Пока он сбрасывается, Close тебя не отпускает.
Суслик (2005-04-25 15:28:00) [132]
> [3] alpet © (25.04.05 15:19)
эттта, виноват, неверный пример написал (упростил сильно) - запись в файл у меня идет в дополнительном потоке, а прерывается процесс в главном потоке. Т.е. про синхронность здесь говорить не приходится.
> [4] mgcr © (25.04.05 15:21)
Игорь, я знаю, что при TermProcess происход CloseHandle для всех объектов, в том числе и для файлов - это явно описано в MSDN. Но я не понимаю, если я (процесс) закрыл handle у файла, почему меня (процесс) кто-то "держит". Т.е. такое ощущение (используя секундомер) меня держар ровно пока файл не запишет все данные из моей памяти. Вот я и спрашиваю - какой тут механизм. Может быть такое, что файл ссылается на процесс, и пока не допишется до конца не делает процессу Closehandle тем самым удерживая процесс в памяти?
mgcr (2005-04-25 15:21:00) [133]
> Какой тут механизм?
CloseHandle
> Но запись то идет из памяти, а память принадлежит процессу,
> т.е. если процесс во время записи в файл "умрет", то и умрет
> его память. Откуда ядро берет данные для записи?
Из кэша.
Память не принадлежит процессу. Память принадлежит диспетчеру памяти и только.
alpet (2005-04-25 15:19:00) [134]Все бы хорошо, да только стандартные функции записи в файл являются синхронными, и после вызова их можно быть уверенным что данные либо в файле, либо в системном кэше.
Суслик (2005-04-25 15:14:00) [135]
> [1] Digitman © (25.04.05 14:55)
ну вроде процесс должен прекратиться.
Кто файл дописывает? Ядро? Какой тут механизм?
Файл - объект ядра. Логично предположить, что процесс дав команду ядру записать в файл данные, уже не может повлиять на процесс записи - ядро данные запишет. Но запись то идет из памяти, а память принадлежит процессу, т.е. если процесс во время записи в файл "умрет", то и умрет его память. Откуда ядро берет данные для записи?
Digitman (2005-04-25 14:55:00) [136]
> почему файл оказывается записанным?
а почему он не должен быть записанным в дан.случае ?