Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Apr 25, 2019 7:35 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 7 posts ] 
Author Message
PostPosted: Sun Sep 06, 2009 2:06 am 
Offline
User avatar

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


Top
   
PostPosted: Sun Sep 06, 2009 2:08 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
а, еще сисфункция (или подфункции) вернуть запрошенные данные/получить данные запроса.

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sun Sep 06, 2009 10:32 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Эта схема, во-первых, приводит к совершенно излишним копированиям данных между процессами, во-вторых, неинтуитивна (/ftp - совсем не то, что ftp://), в-третьих, не может одновременно обрабатывать несколько запросов.

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


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


Top
   
PostPosted: Sun Sep 06, 2009 5:10 pm 
Offline
User avatar

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

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Sun Sep 06, 2009 6:38 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 689
Я бы запретил прикладным программистам думать о том, каким образом в настоящий момент библиотеки загружаются в память и сколько копий там создаётся.

_________________
in code we trust


Top
   
PostPosted: Sun Sep 06, 2009 8:11 pm 
Gluk wrote:
дальше в зависимости от возможностей файлменеджера.

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

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

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 7 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB® Forum Software © phpBB Limited