обработка запросов к фс

Kernel architecture questions
  • а, еще сисфункция (или подфункции) вернуть запрошенные данные/получить данные запроса.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Эта схема, во-первых, приводит к совершенно излишним копированиям данных между процессами, во-вторых, неинтуитивна (/ftp - совсем не то, что ftp://), в-третьих, не может одновременно обрабатывать несколько запросов.
    Ушёл к умным, знающим и культурным людям.
  • Как показывает практика - эмитация и эмуляция чего-либо работает либо медленно, либо с ограничениями. Не имеет смысла распылять силы. Если есть библиотека с какими-либо функциями, то ее не сложно прикрутить к программе.
    Кроме того текущая организация работы файловой системы может обеспечить парралельную работу только с разными устройствами: флопик, жесткий диск и ATAPI привод дисков. Два флопика не будут работать вместе, два жестких диска не будут работать вместе, два ATAPI привода дисков не будут работать вместе. Квазипараллельной работы не предусмотрено - нужно менять алгоритмы, вводить новые семафоры и пр.
  • diamond, ведь можно в ядре разрешить и адрес вида xxx://, и занимать его тоже.. А насчет третьего - приложение ведь может быть многопоточным - само крутится в цикле приема заявок, а для выполнения каждой создавать отдельный поток.
    Mario, да, наверное.. Но в данный момент каждая библиотека загружается в память для каждого приложения, разве нет? И для программы, например, файлмена с фтп это библиотеки архивации, работы с фтп, дальше в зависимости от возможностей файлменеджера.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Я бы запретил прикладным программистам думать о том, каким образом в настоящий момент библиотеки загружаются в память и сколько копий там создаётся.
    in code we trust
  • Gluk wrote:дальше в зависимости от возможностей файлменеджера.
    ИМХО вот в этом вся соль. Объемы наших програм и наших библиотек (даже написанных на ЯВУ) имеют настолько мизерное значение, что проблему можно отбросить. Конечно я не исключаю, что кто-либо начнет генерировать сильно раздутый код, но пока такого мы к счастью не наблюдаем.
    А если тебя все-таки беспокоит, что твоя библиотека будет находиться в нескольких копиях в памяти, то те вещи которые ты предложил вполне можно реализовать организацией процесса-сервера, используя кобминации функций 60 (для передачи сигналов) и 68 (подфункции 22 и 23 для предачи больших объемов данных).
    mike.dld wrote:Я бы запретил прикладным программистам думать о том, каким образом в настоящий момент библиотеки загружаются в память и сколько копий там создаётся.
    Запрещать бесполезно, скорее это рекомендательная инструкция.
  • Who is online

    Users browsing this forum: No registered users and 5 guests