Вопрос по пути ;)

Applications development, KoOS API questions
  • Serge
    Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
    Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
  • В новой 70-й функции буфер не нужен. И данные она измеряет не в блоках, а в байтах.
    Ушёл к умным, знающим и культурным людям.
  • Serge
    Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.
    Мне "очень понравилось" однажды в WinXP, когда приложение заняло файл, аварийно завершилось и при попытке снова запустить его, винда написала, что этот файл уже используется другим приложением. Пришлось перезагружаться. Такие удобства меня не впечатляют.

    rabid rabbit
    Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом
    Кто тебе сказал такое?
    Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.
    Так, например, построены многие вызовы в нелюбимой здесь винде
    Кто тебе сказал, что мы обязательно не любим винду - каждый сам выбирает основную ОС для работы. Я, например не имею нормального линукса, который мне обеспечит все те возможности, которые я использую в Винде. И даже если бы имел остаются еще привычки и игры.
    Кстати, если ядро может выделять память только в стеке, значит, у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено
    Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.

    И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.

    diamond
    Зато нужен стек. Но я не говорю что это не хорошо. Главное, что работает и работает хорошо.
  • Mario79 wrote: Кто тебе сказал такое?
    Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.
    Ты точно уверен, что ничего не поменяется? ;)

    Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.
    Обычно то, что приводят в пример, является единственным возможным вариантом ;)
    И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.
    Здесь нечего переделывать, нужно всё придумывать с нуля.
  • О! Вступай в общество разработчиков дисковой драйверной подсистемы. Вторым будешь. Может хоть что-нибудь начнем делать.
  • Я не против :)
  • halyavin, rabid rabbit И как продвигается?
    Теперь по пунктам рассмотрим все обвинения.
    Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние.
    Могу совершенно точно сказать, что будет в текущей реализации 70-й функции. Вернётся (сразу же) значение 5, file not found. Система действительно не поддерживает понятия текущей папки, но :!: добавить такую поддержку не слишком сложно - ориентировочно порядка сотни-двух строчек на всё про всё (фактически нужно всего лишь хранить идентификатор текущей папки, для FAT достаточно 4-байтового кластера + код для SetCurrentDirectory + проверка в начале 70-й функции). Так как, уже надо?
    Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.
    70-я функция не нуждается в разворачивании имени в 8+3, а потому и буфер для такого разворачивания не нужен. (В файловой структуре даже поля такого нет).
    А чтение файлов фиксированными блоками?
    Для 70-й функции нужно указывать смещение и размер в байтах.
    Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система
    Уже.
    А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако
    Чего нет, того нет (пока?) А это очень нужно? Ведь фактически всё равно потребуется выделить память и прочитать файл в эту память. Так что никакого выигрыша в производительности не будет.
    ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала
    Работу ядра с диском прервать нельзя (если произошло переключение задач и новая задача запросила что-то с диска, то она подождёт, пока не закончит старая программа). Ну а если приложение обращается к ядру порциями, то, как справедливо заметил halyavin,
    Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
    Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
    Ушёл к умным, знающим и культурным людям.
  • а совместный доступ быть не может? вроде как открытие только для чтения в нескольких прогах...
  • Victor
    В текущей реализации совместного доступа нету. Поскольку все потоки равноправны, то любой поток (включая поток ядра) ждет, пока поток начавший дисковую операцию не завершит эту операцию. Одновременно можно обращаться только к разным физическим устройствам, но даже в этом случае нельзя, например, обращаться сразу к 2-м флопикам, потому что контроллер, который их обслуживает, содержится на системной плате в единственном экземпляре. И еще нельзя обращаться одновременно к Master или Slave устройствам по одному и тому же контроллеру, потому что опять таки контроллер один на 2 устройства. Распараллеливание доступа к одному и тому же устройству конечно можно реализовать, но не так скоро. Такую систему надо продумывать. К тому же в PIO режиме ее однозначно не имеет смысла делать вообще, так что сначала надо реализовать режим DMA для винта и сидюка.
  • Тем не менее это всё в ядре; если приложения читают файл небольшими блоками (а хоть бы даже и большими) - без проблем два приложения могут псевдопараллельно читать один файл. (Примерно по той же схеме, что один процессор исполняет кучу программ).
  • Who is online

    Users browsing this forum: No registered users and 9 guests