Інтегровані середовища підтримки робочого столу

Як зазначалося, система X Window є дуже гнучкою. Можна використовувати різ­ні віконні менеджери, розробляти застосування із використанням різних інстру­ментальних бібліотек. Ця гнучкість, однак, має свої недоліки.

♦ Кожний віконний менеджер реалізує керування вікнами по-різному, перехід від одного до іншого зазвичай викликає в користувачів труднощі.

♦ Ще більше проблем пов'язано із відсутністю стандарту на реалізацію інструмен­тальних бібліотек; у результаті маємо, що в разі переходу від одного клієнтсь­кого застосування до іншого доводиться перемикатися між різними підходами до реалізації інтерфейсу користувача, навіть таких його базових компонентів, як прокручування або організація стандартних вікон відкриття файла.

♦ Кожну інструментальну бібліотеку потрібно поміщати у пам'ять під час за­вантаження відповідного застосування, що спричиняє додаткові витрати па­м'яті у тому випадку, коли одночасно у пам'ять завантажено кілька застосу­вань, що використовують різні бібліотеки. _1вє ьи-*-

♦ Відсутній стандарт на базові застосування для керування системою, такі як панель керування або файловий менеджер. Є багато реалізацій цих засобів, несумісних за інтерфейсом один з одним.

Для вирішення цих проблем запропоновано концепцію інтегрованого середо­вища підтримки робочого столу (desktop environment). Таке середовище — це інтегрований набір застосувань та інструментальних бібліотек, що реалізують весь набір засобів для організації роботи користувача під управлінням системи X Window. Найчастіше туди входять інструментальна бібліотека, віконний мене­джер і базові застосування для керування системою. Фактично, воно реалізує на­бір компонентів, стандартних для інтерфейсу користувача Windows-систем.

В сучасних ОС широко використовують два інтегровані середовища підтрим­ки робочого столу: KDE і GNOME. Особливості реалізації KDE наведено нижче.

KDE містить:

♦ інструментальну бібліотеку (Qt), яку використовують для реалізації всіх KDE-застосувань і рекомендують як стандарт для розробників;

♦ віконний менеджер (kwm), що підтримує керування вікнами на основі домо­вленостей, прийнятих у Windows-системах;

♦ набір додаткових бібліотек високого рівня (kdelibs), що реалізують складніші елементи керування (наприклад, діалогові вікна), а також базові системні функ­ції (наприклад, друкування документів);

♦ набір домовленостей із розробки інтерфейсу користувача;

♦ набір прикладних програм для розв'язання базових задач повсякденної робо­ти в системі (веб-браузер і файловий менеджер Konqueror, панель керування control panel, засіб запуску застосувань kpanel, емулятор термінала kconsole тощо).

GNOME має подібну функціональність, важливою відмінністю є те, що це се­редовище дає змогу вибирати між різними віконними менеджерами, не віддаючи переваги якомусь одному.

 

Процеси без взаємодії із користувачем

Дотепер ми розглядали особливості організації взаємодії із користувачем під час розробки інтерактивних процесів. Ще одним видом такої організації є відсутність взаємодії, що становить основну характеристику фонових процесів. Особливості їхньої розробки є темою цього розділу.

 

Фонові процеси на основі POSIX

У цьому розділі ознайомимося із особливостями розробки фонових процесів у UNIX-сумісних системах [33, 52]. У них фонові процеси за традицією називають демонами (daemons). До стандартних демонів Linux належать: і nit, що є предком усіх процесів системи; сгоп, що забезпечує запуск програм у певні моменти часу; sendmail, що забезпечує відсилання та отримання електронної пошти тощо.

 

Сесії та групи процесів

Кожен процес належить до групи процесів, яку позначають ідентифікатором гру­пи процесів (pgid). Ядро може виконувати певні дії над усіма процесами групи (наприклад, відсилати їм усім сигнал). Кожна група може мати лідера групи (у цього процесу ідентифікатор (pid) збігається з ідентифікатором групи). Зви­чайно процес успадковує ідентифікатор групи від свого предка, він може також явно змінити свою групу системним викликом setpgrpO.

Усі процеси групи володіють одним і тим самим керуючим терміналом у кон­кретний момент часу, під час виконання він може змінюватися. У групи такого термінала може і зовсім не бути - у цьому разі її процеси не отримуватимуть сиг­налів від клавіатури.

Кілька груп процесів об'єднують у сесію. Для сесії задають ідентифікатор сесії (sid). Звичайно процеси сесії відповідають набору процесів, які створив користу­вач під час інтерактивного сеансу роботи з системою.

Кожний керуючий термінал пов'язаний із сесією та з однією групою процесів цієї сесії (таку групу називають ще інтерактивною (foreground) групою, усі інші називають фоновими (background), з ними термінали не пов'язані). Протилежне, як і для груп, не завжди вірне - сесія може бути взагалі не пов'язана із керуючим терміналом, у цьому випадку в неї відсутня інтерактивна група.

У кожної сесії є лідер сесії, який відповідає за керування сесією та ізоляцію її від інших; його ідентифікатор збігається з ідентифікатором сесії. Якщо лідер сесії пов'язаний із терміналом, у разі виходу користувача з системи цей процес отри­мує сигнал SIGHUP. Звичайною реакцією на цей сигнал буде завершення роботи процесу-лідера та всіх процесів його сесії.

Коли лідер сесії із терміналом не пов'язаний, сигналу про вихід він не отримає і зможе продовжити виконання після закінчення сеансу роботи. Це особливо важливо для фонових процесів.

Взаємозв'язок між сесіями, групами процесів і керуючими терміналами пока­зана на рис. 17.3.

 

 

 

Створення нової сесії

Подивимось, як користувач може створити нову сесію і для чого це може знадо­битися. Нову сесію створюють за допомогою системного виклику setsidO. Під час його виконання

створюють сесію, і поточний процес стає її лідером;

створюють нову групу процесів у рамках сесії, і поточний процес стає її лідером;

для поточного процесу розривають зв'язок із керуючим терміналом, якщо вія був.

У результаті буде створено сесію без керуючого термінала та з однією фоно­вою групою всередині неї, що містить на цей момент один процес. Цим як поточ­ний процес, так і його нащадки будуть захищені від сигналів з клавіатури та сиг­налу про вихід із системи, тобто будуть коректно переведені у фоновий режим. Саме так необхідно реалізовувати фонові процеси, які передбачають використо­вувати незалежно від наявності інтерактивних сеансів користувачів у системі.

Зазначимо, що, якщо процес уже є лідером групи процесів, виклик setsidO призведе до помилки. Для того щоб її уникнути, рекомендують спочатку створи­ти нащадка процесу за допомогою fork() (він гарантовано не буде лідером групи), у ньому викликати setsidO, а предка завершити.

 

Розробка фонового процесу

До фонового процесу ставлять такі вимоги: він повинен утворювати власну сесію і групу процесів, не може належати до жодної із сесій і груп користувача та мати керуючий термінал.

Причини висунення цих вимог наведено нижче.

♦ Демон не може мати керуючого термінала, оскільки не повинен реагувати на пе-

­реривання у разі спроб введення-виведення із використанням такого термінала.

♦ Демон має бути лідером фонової групи процесів і лідером нової сесії, щоб він не міг отримувати сигнали (наприклад, у разі натискання Ctrl+C або виходу із системи).

 

Після запуску демон закриває всі відкриті файли, особливо стандартні потоки введення-виведення, оскільки вони мають бути закриті після виходу користувача із системи, а демон має продовжувати роботу і після цього.

Для того щоб дотриматися всіх вимог, у демоні потрібно виконати певну пос­лідовність дій.

 

1. Відразу після запуску процес демона має створити нащадка:

 

if ((pid = fork()) < 0) return -1;

 

Це потрібно для того, щоб відразу повернутися в командний процесор, вий­шовши з предка на кроці 2. Щоб новий процес гарантовано не міг стати ліде­ром групи процесів, бо він успадковує цю групу від предка - це потрібно пізні­ше для виклику setsidO на кроці 3.

 

2. Після створення нащадка предок має завершити свою роботу:

if (pid!- 0) { // предок

printf ("демон стартував з pid=£d\n", pid);

exit (0):

 

4. Інші кроки відбуваються в нащадку. У ньому потрібно виконати певну послі­довність дій.

5.

♦ Створити нову сесію:

 

setsidO:

 

Поточний процес внаслідок виклику setsidO, як було сказано раніше, стає лідером нової сесії, лідером групи процесів і не має керуючого термінала. Головний сенс цього виклику — відключитися від керуючого термінала і втратити зв'язок із поточною сесією, щоб не одержувати ніяких сигналів.

 

♦ Змінити поточний каталог на кореневий каталог системи або конкретний робочий каталог демона:

 

chdirCV");

 

Якщо цього не зробити, поточний каталог демона завжди буде тим, з якого він запущений. Тут є ризик, що поточним може виявитися каталог, у який замонтовано файлову систему (у цьому випадку її не можна буде розмонту­вати, поки демон не закінчить роботу).

 

♦ Можливо, закрити всі відкриті файли (файлові дескриптори):

 

// закрити наперед визначені дескриптори

for (fd = 0: fd < 3; fd++) close(fd):

 

♦ Перейти в режим очікування (вже було розглянуто різні способи задания очікування у серверних процесах, найпростіший спосіб — виконати виклик pauseO у циклі):

 

for (;;) pause()і

 

Після запуску демон буде лідером сесії (pid=sid), лідером групи процесів (pid=pgid) і не матиме керуючого термінала, а його предком стане і nit, оскільки безпосередній предок припинив виконання.

 

Служби Windows ХР

Аналогом демонів у Windows ХР є служби (services) - фонові процеси, які мо­жуть виконуватися навіть тоді, коли із системою не працює жоден користувач [32, 50]. Із розділу 2 вже відомо про те, що за керування службами відповідає ме­неджер служб (Service Control Manager). Він приймає керуючі команди від засто­сувань і відповідно до них виконує дії зі службами (наприклад, запускає на вико­нання або зупиняє).

Користувацький інтерфейс менеджера служб реалізовано двома способами:

♦ за допомогою вікна керування службами (Services), яке викликають через під-меню Administrative Tools головного меню системи (це вікно відображає список служб, дає змогу запускати і зупиняти окремі служби, дізнаватися про їхні властивості тощо);

♦ за допомогою утиліти net. ехе, що входить у поставку Windows ХР; наприк­лад, команда net start ім'я_служби дає команду менеджерові запустити відпо­відну службу, net stop і м' я_служби - зупинити її.

Для керування службами необхідно мати адміністративні права у системі.