Page 3 of 3
Posted: Mon May 29, 2006 9:45 pm
by rabid rabbit
Mario79 wrote:
Я конечно отмазываюсь, но:
1) Это разработано еще Великом - большим специалистом по написанию ОС (он уже 4-ю ОС пишет, насколько я понимаю).
2) Что офигительного в выделении буфера в области приложения? Приложение что жаба задушит?
Ядро все равно с одинаково скоростью организует доступ, что к памяти, отведенной под себя, что к памяти отведенной к приложению.
Конкретно выделив место под буфер, нет нужды занимать стек, то есть, он лишний раз не распухнет, и не дойдет критического значения, то есть не пересечет выделенную для него область.
Теперь приведи свои доводы против такой реализации (не считая эмоций) и того, что так не привычно, я с удовольствием выслушаю и возможно мы изменим ситуацию.
Тут
Serge уже выступил, но и у меня есть, что добавить
Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом
Если уж так повелось переложить задачу выделения этого несчастного буфера на приложение, можно предусмотреть вызов, который скажет приложению, какого размера буфер выделить. Так, например, построены многие вызовы в нелюбимой здесь винде
Кстати, если ядро может выделять память только в стеке, значит у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено
Posted: Tue May 30, 2006 7:25 am
by halyavin
Serge
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
Posted: Tue May 30, 2006 10:09 am
by diamond
В новой 70-й функции буфер не нужен. И данные она измеряет не в блоках, а в байтах.
Posted: Tue May 30, 2006 6:00 pm
by Mario79
Serge
Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.
Мне "очень понравилось" однажды в WinXP, когда приложение заняло файл, аварийно завершилось и при попытке снова запустить его, винда написала, что этот файл уже используется другим приложением. Пришлось перезагружаться. Такие удобства меня не впечатляют.
rabid rabbit
Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом
Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.
Так, например, построены многие вызовы в нелюбимой здесь винде
Кто тебе сказал, что мы обязательно не любим винду - каждый сам выбирает основную ОС для работы. Я, например не имею нормального линукса, который мне обеспечит все те возможности, которые я использую в Винде. И даже если бы имел остаются еще привычки и игры.
Кстати, если ядро может выделять память только в стеке, значит, у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено
Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.
И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.
diamond
Зато нужен стек. Но я не говорю что это не хорошо. Главное, что работает и работает хорошо.
Posted: Tue May 30, 2006 6:54 pm
by rabid rabbit
Mario79 wrote:
Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.
Ты точно уверен, что ничего не поменяется?
Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.
Обычно то, что приводят в пример, является единственным возможным вариантом
И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.
Здесь нечего переделывать, нужно всё придумывать с нуля.
Posted: Tue May 30, 2006 9:03 pm
by halyavin
О! Вступай в общество разработчиков дисковой драйверной подсистемы. Вторым будешь. Может хоть что-нибудь начнем делать.
Posted: Tue May 30, 2006 10:00 pm
by rabid rabbit
Я не против
Posted: Tue Jun 20, 2006 5:15 pm
by diamond
halyavin, rabid rabbit И как продвигается?
Теперь по пунктам рассмотрим все обвинения.
Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние.
Могу совершенно точно сказать, что будет в текущей реализации 70-й функции. Вернётся (сразу же) значение 5, file not found. Система действительно не поддерживает понятия текущей папки, но
добавить такую поддержку не слишком сложно - ориентировочно порядка сотни-двух строчек на всё про всё (фактически нужно всего лишь хранить идентификатор текущей папки, для FAT достаточно 4-байтового кластера + код для SetCurrentDirectory + проверка в начале 70-й функции). Так как, уже надо?
Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.
70-я функция не нуждается в разворачивании имени в 8+3, а потому и буфер для такого разворачивания не нужен. (В файловой структуре даже поля такого нет).
А чтение файлов фиксированными блоками?
Для 70-й функции нужно указывать смещение и размер
в байтах.
Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система
Уже.
А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако
Чего нет, того нет (пока?) А это очень нужно? Ведь фактически всё равно потребуется выделить память и прочитать файл в эту память. Так что никакого выигрыша в производительности не будет.
ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала
Работу ядра с диском прервать нельзя (если произошло переключение задач и новая задача запросила что-то с диска, то она подождёт, пока не закончит старая программа). Ну а если приложение обращается к ядру порциями, то, как справедливо заметил
halyavin,
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
Posted: Tue Jun 20, 2006 6:39 pm
by vectoroc
а совместный доступ быть не может? вроде как открытие только для чтения в нескольких прогах...
Posted: Tue Jun 20, 2006 7:06 pm
by Mario79
Victor
В текущей реализации совместного доступа нету. Поскольку все потоки равноправны, то любой поток (включая поток ядра) ждет, пока поток начавший дисковую операцию не завершит эту операцию. Одновременно можно обращаться только к разным физическим устройствам, но даже в этом случае нельзя, например, обращаться сразу к 2-м флопикам, потому что контроллер, который их обслуживает, содержится на системной плате в единственном экземпляре. И еще нельзя обращаться одновременно к Master или Slave устройствам по одному и тому же контроллеру, потому что опять таки контроллер один на 2 устройства. Распараллеливание доступа к одному и тому же устройству конечно можно реализовать, но не так скоро. Такую систему надо продумывать. К тому же в PIO режиме ее однозначно не имеет смысла делать вообще, так что сначала надо реализовать режим DMA для винта и сидюка.
Posted: Tue Jun 20, 2006 7:14 pm
by diamond
Тем не менее это всё в ядре; если приложения читают файл небольшими блоками (а хоть бы даже и большими) - без проблем два приложения могут псевдопараллельно читать один файл. (Примерно по той же схеме, что один процессор исполняет кучу программ).