Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

2004 г.

Особенности программирования BeOS API для пришельцев - введение. Часть 1-я.

Сергей Долгов, www.qube.ru

Невозможно рассказать об особенностях программирования в BeOS, не упомянув одну особенность архитектуры этой ОС - модульность. BeOS целиком построен на основе сервисов, или серверов (servers) - программных демонов (в юникс-терминологии). Таких как Сервер Приложений (Application Server), выполняющий отрисовку всего видимого слоя в BeOS и обеспечивающего общение программ с системой и между собой. Или Медиа-Сервер (MediaServer) - превращающий медиа-потоки в звук и видео. Все вызовы функций/методов BeOS API из пользовательской программы в подавляющем числе случаев выполняются одним из этих серверов. В иерархии слоев ОС эти сервера находятся на уровне обычной пользовательской программы. То есть имеют те же права и методы доступа к системным ресурсом (памяти, процессору, периферии), как и гипотетическая "любая обычная" программа. А это значит, что ошибка в пользовательской программе вызовет в худшем случае падение только этого сервера (во многих случаях его можно перезапустить, "не отходя от кассы", то есть не перегружая всю систему - как многие из вас делали с NetServer или MediaServer).

Кроме того, каждый из серверов запускает множество практически независимых потоков (threads, дословно - нить) для обслуживания обращений от других программ, поэтому, во многих случаях, умирает лишь "поврежденный" поток. Такие умирающие не своей смертью потоки вылавливаются постоянно действующей "ловушкой для клопов и соломкой для падений" - Debug Server. Для последующей экспертизы. Причем, это не совсем паталогоанатомия трупа - до закрытия окна Debug Server поток находится в состоянии всего лишь клинической смерти, ему могут быть сделаны анализы, а иногда он может быть даже реанимирован

.

Наиболее важный из них для нашего дальнейшего разговора - это, естественно, Application Server, обеспечивающий наибольшую часть функциональности программ. Не то, что бы мы его намеревались упоминать направо и налево, но во всем дальнейшем разговоре он будет играть роль "серого кардинала".

В принципе, AppServer - хорошая иллюстрация быстрой и эффективной клиент-серверной архитектуры для графического интерфейса пользователя (GUI).

То, о чем десктопный юникс-народ с их X11 может пока только мечтать (о сетевой функциональности X11 здесь речь не идет, тем более, что в версии BeOS 5.1 по имеющимся сведениям, вся эта клиент-серверность с тем же успехом работала и через сеть).

Впрочем, есть и другой пример эффективной реализации этой идеи - Photon в операционной системе QNX.

Значительная заслуга во впечатляющей работе AppServer принадлежит многопоточности.

Наверное надо чуть пояснить про потоки. Начинающие программисты, даже программируя в многозадачной среде, редко в явном виде сталкиваются с этим зверем. В BeOS же без него ни шагу не ступить. Или, скорее невозможно на эти грабли не наступить. Образно говоря, это такой минимальный целостный кусок исполняемого кода, у которого может создаться впечатление, что он настолько самый главный, что все ресурсы машины принадлежат ему одному.

Концепция потоков является развитием концепции многозадачности. На всякий пожарный, поясню и это.

Вас никогда не удивляло, что процессор, как правило - один, видеокарта, скажем, тоже одна - а тем не менее вроде все программы выполняются одновременно и другу другу не мешают (хехе, вот тут и отличие грамотно сделанной ОС от...)? Делается это за счет очень быстрого переключения процессора с одного куска кода на другой. Для временно осиротевшего кода запоминается его состояние и частично состояние ОС в момент остановки, то есть всяческие данные, необходимые для последующей реанимации.

Вот такой исполняющийся код, вместе с этими самыми постоянно обновляемыми "реанимационными данными", и есть процесс, или задача. В былые времена весь код, относящейся к одной программе, обычно и представлял из себя единый и единственный процесс. Теперь же и единая программа может из себя представлять целый набор параллельно выполняющихся кусков, тем самых потоков-нитей (threads). В целом же потоки-нити одной программы образуют связку - team. При этом каждый из потоков программы может получить некоторый доступ к общим для team данным.

При последовательной и аккуратной реализации многопоточности можно заметно повысить эффективность и отдельных программ, и всей ОС. Кроме того, это сильно облегчает реализацию Симметричной Многопроцессорности (SMP).

Поскольку тут не придется специально заботиться, как загрузить крутую многопроцессорную тачку - каждый поток может быть отдан любому из процессоров, на котором сейчас потоков меньше - без долгих раздумий и разбора обстоятельств. Счастливчики с BeOS на многопроцессорной тачке могут воочию наблюдать этот радующий сердце факт при помощи программы ProcessController.

Теперь можно спуститься и поближе к земле, то есть к BeOS API. Единственно, что меня слегка гложет - это степень необходимости пояснения понятия Объектно Ориентированного Программирования (OOP) по ходу текста.

Хотя нынешняя молодежь должны была бы всосать это дело с первым глотком кока-колы, мой опыт показывает, что это не так. Хотя даже VisualBasic дает (тем кто интересуется) достаточный опыт, оказывается, что и активные пользователи таких объектных сред как Delphi и BorlandBuilder зачастую имеют о предмете весьма смутное представление. Так что заранее прошу OOP-гуру извинить меня за последующее занудство и некоторый примитивизм:)

Для удобства программиста (который тоже человек:), весь набор фунций/методов для BeOS разбит на инструментальные комплекты - Kits. Например Networking Kit, Media Kit, Storage Kit. Сейчас нас будут интересовать два из них Инструментарий Приложений - Application Kit и Инструментарий Интерфейса - Interface Kit.

На все это дело можно взглянуть в библии BeOS-програмирования, BeBook.

В интернете - http://www.beclan.org/BeBook/

или, если вы уже поставили комплект разработчика BeOS - BeOS Development Tools - на вашем диске:
file:///boot/beos/documentation/Be%20Book/index.html

Начнем с головы, точнее с двух - main() и be_app. И если первое слово знакомо каждому С-шнику, то второе - уже чистый BeOS.

Далее
Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...