Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Apr 18, 2021 11:49 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 41 posts ]  Go to page Previous 1 2 3
Author Message
 Post subject:
PostPosted: Mon May 29, 2006 9:45 pm 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
Mario79 wrote:
Я конечно отмазываюсь, но:
1) Это разработано еще Великом - большим специалистом по написанию ОС (он уже 4-ю ОС пишет, насколько я понимаю).
2) Что офигительного в выделении буфера в области приложения? Приложение что жаба задушит?
Ядро все равно с одинаково скоростью организует доступ, что к памяти, отведенной под себя, что к памяти отведенной к приложению.
Конкретно выделив место под буфер, нет нужды занимать стек, то есть, он лишний раз не распухнет, и не дойдет критического значения, то есть не пересечет выделенную для него область.
Теперь приведи свои доводы против такой реализации (не считая эмоций) и того, что так не привычно, я с удовольствием выслушаю и возможно мы изменим ситуацию.


Тут Serge уже выступил, но и у меня есть, что добавить ;) Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом ;) Если уж так повелось переложить задачу выделения этого несчастного буфера на приложение, можно предусмотреть вызов, который скажет приложению, какого размера буфер выделить. Так, например, построены многие вызовы в нелюбимой здесь винде ;)
Кстати, если ядро может выделять память только в стеке, значит у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено ;)


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 7:25 am 
Serge
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 10:09 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
В новой 70-й функции буфер не нужен. И данные она измеряет не в блоках, а в байтах.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 6:00 pm 
Serge
Quote:
Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.

Мне "очень понравилось" однажды в WinXP, когда приложение заняло файл, аварийно завершилось и при попытке снова запустить его, винда написала, что этот файл уже используется другим приложением. Пришлось перезагружаться. Такие удобства меня не впечатляют.

rabid rabbit
Quote:
Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом

Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.

Quote:
Так, например, построены многие вызовы в нелюбимой здесь винде

Кто тебе сказал, что мы обязательно не любим винду - каждый сам выбирает основную ОС для работы. Я, например не имею нормального линукса, который мне обеспечит все те возможности, которые я использую в Винде. И даже если бы имел остаются еще привычки и игры.

Quote:
Кстати, если ядро может выделять память только в стеке, значит, у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено

Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.

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

diamond
Зато нужен стек. Но я не говорю что это не хорошо. Главное, что работает и работает хорошо.


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 6:54 pm 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
Mario79 wrote:
Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.


Ты точно уверен, что ничего не поменяется? ;)


Quote:
Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.


Обычно то, что приводят в пример, является единственным возможным вариантом ;)

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


Здесь нечего переделывать, нужно всё придумывать с нуля.


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 9:03 pm 
О! Вступай в общество разработчиков дисковой драйверной подсистемы. Вторым будешь. Может хоть что-нибудь начнем делать.


Top
   
 Post subject:
PostPosted: Tue May 30, 2006 10:00 pm 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
Я не против :)


Top
   
 Post subject:
PostPosted: Tue Jun 20, 2006 5:15 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
halyavin, rabid rabbit И как продвигается?
Теперь по пунктам рассмотрим все обвинения.
Quote:
Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние.

Могу совершенно точно сказать, что будет в текущей реализации 70-й функции. Вернётся (сразу же) значение 5, file not found. Система действительно не поддерживает понятия текущей папки, но :!: добавить такую поддержку не слишком сложно - ориентировочно порядка сотни-двух строчек на всё про всё (фактически нужно всего лишь хранить идентификатор текущей папки, для FAT достаточно 4-байтового кластера + код для SetCurrentDirectory + проверка в начале 70-й функции). Так как, уже надо?
Quote:
Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.

70-я функция не нуждается в разворачивании имени в 8+3, а потому и буфер для такого разворачивания не нужен. (В файловой структуре даже поля такого нет).
Quote:
А чтение файлов фиксированными блоками?

Для 70-й функции нужно указывать смещение и размер в байтах.
Quote:
Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система

Уже.
Quote:
А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако

Чего нет, того нет (пока?) А это очень нужно? Ведь фактически всё равно потребуется выделить память и прочитать файл в эту память. Так что никакого выигрыша в производительности не будет.
Quote:
ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала

Работу ядра с диском прервать нельзя (если произошло переключение задач и новая задача запросила что-то с диска, то она подождёт, пока не закончит старая программа). Ну а если приложение обращается к ядру порциями, то, как справедливо заметил halyavin,
Quote:
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Tue Jun 20, 2006 6:39 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
а совместный доступ быть не может? вроде как открытие только для чтения в нескольких прогах...


Top
   
 Post subject:
PostPosted: Tue Jun 20, 2006 7:06 pm 
Victor
В текущей реализации совместного доступа нету. Поскольку все потоки равноправны, то любой поток (включая поток ядра) ждет, пока поток начавший дисковую операцию не завершит эту операцию. Одновременно можно обращаться только к разным физическим устройствам, но даже в этом случае нельзя, например, обращаться сразу к 2-м флопикам, потому что контроллер, который их обслуживает, содержится на системной плате в единственном экземпляре. И еще нельзя обращаться одновременно к Master или Slave устройствам по одному и тому же контроллеру, потому что опять таки контроллер один на 2 устройства. Распараллеливание доступа к одному и тому же устройству конечно можно реализовать, но не так скоро. Такую систему надо продумывать. К тому же в PIO режиме ее однозначно не имеет смысла делать вообще, так что сначала надо реализовать режим DMA для винта и сидюка.


Top
   
 Post subject:
PostPosted: Tue Jun 20, 2006 7:14 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1600
Тем не менее это всё в ядре; если приложения читают файл небольшими блоками (а хоть бы даже и большими) - без проблем два приложения могут псевдопараллельно читать один файл. (Примерно по той же схеме, что один процессор исполняет кучу программ).


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 41 posts ]  Go to page Previous 1 2 3

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited