QNX/UNIX: Анатомия параллелизма - Цилюрик Олег Иванович Страница 11
- Категория: Компьютеры и Интернет / Интернет
- Автор: Цилюрик Олег Иванович
- Страниц: 106
- Добавлено: 2020-09-16 22:14:02
QNX/UNIX: Анатомия параллелизма - Цилюрик Олег Иванович краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «QNX/UNIX: Анатомия параллелизма - Цилюрик Олег Иванович» бесплатно полную версию:Книга адресована программистам, работающим в самых разнообразных ОС UNIX. Авторы предлагают шире взглянуть на возможности параллельной организации вычислительного процесса в традиционном программировании. Особый акцент делается на потоках (threads), а именно на тех возможностях и сложностях, которые были привнесены в технику параллельных вычислений этой относительно новой парадигмой программирования. На примерах реальных кодов показываются приемы и преимущества параллельной организации вычислительного процесса. Некоторые из результатов испытаний тестовых примеров будут большим сюрпризом даже для самых бывалых программистов. Тем не менее излагаемые техники вполне доступны и начинающим программистам: для изучения материала требуется базовое знание языка программирования C/C++ и некоторое понимание «устройства» современных многозадачных ОС UNIX.
В качестве «испытательной площадки» для тестовых фрагментов выбрана ОСРВ QNX, что позволило с единой точки зрения взглянуть как на специфические механизмы микроядерной архитектуры QNX, так и на универсальные механизмы POSIX. В этом качестве книга может быть интересна и тем, кто не использует (и не планирует никогда использовать) ОС QNX: программистам в Linux, FreeBSD, NetBSD, Solaris и других традиционных ОС UNIX.
QNX/UNIX: Анатомия параллелизма - Цилюрик Олег Иванович читать онлайн бесплатно
Правила наследования (и ненаследования) параметров дочернего процесса от родителя (RID, RGID и других атрибутов) жестко регламентированы, достаточно сложны (в зависимости от флагов) и могут быть уточнены в технической документации QNX. Отметим, что безусловно наследуются такие параметры, как: а) приоритет и дисциплина диспетчеризации; б) рабочий и корневой каталоги файловой системы. Не наследуются: установки таймеров процесса tms_utime, tms_stime, tms_cutimeи tms_cstime, значение взведенного сигнала SIGALRM(это значение сбрасывается в ноль), файловые блокировки, блокировки и отображения памяти (shared memory), установленные родителем.
При успешном завершении вызов функции возвращает PID порожденного процесса. При неудаче возвращается -1 и errnoустанавливается:
• E2BIG— количество байт, заданное в списке аргументов или переменных окружения и превышающее ARG_MAX;
• EACCESS— нет права поиска в каталогах префикса имени файла, или для файла не установлены права на выполнение, или файловая система по указанному пути была смонтирована с флагом ST_NOEXEC;
• EAGAIN— недостаточно системных ресурсов для порождения процесса;
• ERADF— недопустим хотя бы один из файловых дескрипторов в массиве fd_map;
• EFAULT— недопустима одна из буферных областей, указанных в вызове;
• ELOOP— слишком глубокий уровень символических ссылок к файлу или глубина префиксов (каталогов) в полном пути к файлу;
• EMFILE— недостаточно ресурсов для отображения файловых дескрипторов в дочерний процесс;
• ENAMETOOLONG— длина полного пути превышает PATH_MAXили длина компонента имени файла и пути превышает NAME_MAX;
• ENOENT— файл нулевой длины или несуществующий префиксный компонент в полном пути;
• ENOEXEC— файл, указанный как программа, имеет ошибочный для исполняемого файла формат;
• ENOMEM— в системе недостаточно свободной памяти для порождения процесса;
• ENOSYS— файловая система, специфицированная полным путевым именем файла, не предназначена для выполнения spawn();
• ENOTDIR— префиксные компоненты пути исполняемого файла не являются каталогами;
Даже из этого очень краткого обзора вызова spawn()становятся очевидными некоторые вещи:
• Эта форма универсальна (самодостаточна), она позволяет обеспечить весь спектр разнообразных форм порождения нового процесса
• Она же и самая громоздкая форма, тяжеловесная для практического кодирования, поэтому в реальных текстах в большинстве случаев вы вместо нее встретите ее конкретизации: spawnl(), spawnle(), spawnlp(), spawnlpe(), spawnp(), spawnv(), spawnve(), spawnvp(), spawnvpe(). Все эти формы достаточно полно описаны в [1]. Функционально они эквивалентны spawn(), поэтому мы не станем на них детально останавливаться.
• Хотя вызов spawn()и упоминается в описаниях как POSIX-совместимый, в QNX он существенно расширен и модифицирован и поэтому в лучшем случае может квалифицироваться как «выполненный по мотивам» POSIX.
В качестве примера приведем использованную в [4] (глава Д. Алексеева «Утилита on») форму вызова для запуска программы (с именем, заданным в строке command) на удаленном узле node(например, /net/xxx) сети QNET (как вы понимаете, это совершенно уникальная возможность QNX, говорить о которой в рамках POSIX-совместимости просто бессмысленно):
int main() {
char* command = "...", *node = "...";
// параметры запуска не используются
char* const argv[] = { NULL };
struct inheritance inh;
inh.flags = 0;
// флаг удаленного запуска
inh.flags |= SPAWN_SETND;
// дескриптор хоста
inh.nd = netmgr_strtond(node, NULL);
pid_t pid = spawnp(command, 0, NULL, &inh, argv, NULL);
...
}
Использованная здесь форма spawnp()наиболее близка к базовой spawn()и отличается лишь тем, что для поиска файла программы используется переменная системного окружения PATH.
Приведем характерный пример вызова группы exec*():
int execl(const char* path, const char* arg0, const char* arg1, ...
const char* argn, NULL);
где path— путевое имя исполняемого файла; arg0, …, argn— символьные строки, доступные процессу как список аргументов. Список аргументов должен завершаться значением NULL. Аргумент arg0должен быть именем файла, ассоциированного с запускаемым процессом.
ПримечаниеУстоявшаяся терминология «запускаемый процесс» относительно exec*()явно неудачна и лишь вводит в заблуждение. Здесь гораздо уместнее говорить о замещении выполнявшегося до этой точки кода новым, выполнение которого начинается с точки входа главного потока замещающего процесса.
ПримечаниеЕсли вызов exec*()выполняется из многопоточного родительского процесса, то все выполняющиеся потоки этого процесса предварительно завершаются. Никакие функции деструкторов для них не выполняются.
Если вызов exec*()успешен, управление никогда уже не возвращается в точку вызова. В случае неудачи возвращается -1 и errnoустанавливается так же, как описано выше для spawn().
Жалоба
Напишите нам, и мы в срочном порядке примем меры.