Board.KolibriOS.org

У меня была такая идея по поводу Колибри.. Что если можно было бы разррешать приложениям перехватывать запросы к файлам, это могло бы дать интересные результаты.. Что я имею ввиду: некое приложение говорит системе, мол, передавай мне запросы к папке (например) '/ftp/' и когда любой файлмен запрашивает файл например '/ftp/anonimous@ftp.kolibrios.org/somefile', это приложение получает этот запрос, обрабатывает, и выдает результат в таком виде как вернула бы обычная сисфункция чтения файла.. И система эти данные возвращает от своего имени..
Для реализации такой схемы от ядра нужна новая сисфункция (занять/освободить занятый адрес в системе), и новое событие (получен запрос к занятому адресу). Для чего это нужно? Можно будет
-не дописывать файловым менеджерам работу с сетью, вместо этого написать соответствующие программы-обработчики для разных протоколов.
-заняв например адрес *.zip как папку, можно будет не дописывать файлменам работу с такими архивами.
-в новых приложениях для работы с сетью тоже удобно, два браузера например могут использовать один обработчик, который может даже кэшировать если надо.
-и т.д..
Как вам идея?

а, еще сисфункция (или подфункции) вернуть запрошенные данные/получить данные запроса.

Эта схема, во-первых, приводит к совершенно излишним копированиям данных между процессами, во-вторых, неинтуитивна (/ftp - совсем не то, что ftp://), в-третьих, не может одновременно обрабатывать несколько запросов.

Как показывает практика - эмитация и эмуляция чего-либо работает либо медленно, либо с ограничениями. Не имеет смысла распылять силы. Если есть библиотека с какими-либо функциями, то ее не сложно прикрутить к программе.
Кроме того текущая организация работы файловой системы может обеспечить парралельную работу только с разными устройствами: флопик, жесткий диск и ATAPI привод дисков. Два флопика не будут работать вместе, два жестких диска не будут работать вместе, два ATAPI привода дисков не будут работать вместе. Квазипараллельной работы не предусмотрено - нужно менять алгоритмы, вводить новые семафоры и пр.

diamond, ведь можно в ядре разрешить и адрес вида xxx://, и занимать его тоже.. А насчет третьего - приложение ведь может быть многопоточным - само крутится в цикле приема заявок, а для выполнения каждой создавать отдельный поток.
Mario, да, наверное.. Но в данный момент каждая библиотека загружается в память для каждого приложения, разве нет? И для программы, например, файлмена с фтп это библиотеки архивации, работы с фтп, дальше в зависимости от возможностей файлменеджера.

Я бы запретил прикладным программистам думать о том, каким образом в настоящий момент библиотеки загружаются в память и сколько копий там создаётся.

Gluk wrote:дальше в зависимости от возможностей файлменеджера.

ИМХО вот в этом вся соль. Объемы наших програм и наших библиотек (даже написанных на ЯВУ) имеют настолько мизерное значение, что проблему можно отбросить. Конечно я не исключаю, что кто-либо начнет генерировать сильно раздутый код, но пока такого мы к счастью не наблюдаем.
А если тебя все-таки беспокоит, что твоя библиотека будет находиться в нескольких копиях в памяти, то те вещи которые ты предложил вполне можно реализовать организацией процесса-сервера, используя кобминации функций 60 (для передачи сигналов) и 68 (подфункции 22 и 23 для предачи больших объемов данных).

mike.dld wrote:Я бы запретил прикладным программистам думать о том, каким образом в настоящий момент библиотеки загружаются в память и сколько копий там создаётся.

Запрещать бесполезно, скорее это рекомендательная инструкция.