Особенности программирования BeOS API Часть 1 (введение)

автор:&#160&#160&#160 Сергей Долгов
источник: 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.


При использовании материалов сайта ссылка обязательна! (Copyright by www.avs-info.ru 2006)