Unix

Боровский А. Программирование для Unix [Текст] : Часть 9: Демоны / Андрей Боровский  //  Linux Format. — 2007. — № 2 (89), февр. — С. 78-81. — (Программирование для Unix. Учебник). 
     Аннотация
     Демоны в мире Unix — процессы, которые не взаимодействуют с пользователем напрямую. У процесса-демона нет управляющего терминала и, соответственно, нет пользовательского интерфейса. Для управления демонами приходится использовать другие программы. Само название "демоны" возникло благодаря тому, что многие процессы (не все) этого типа большую часть времени проводят в ожидании какого-то события. Когда это событие наступает, демон активизируется (выпрыгивает, как чертик из табакерки), выполняет свою работу и снова засыпает в ожидании события. 
     Демоны делают всю "черную работу" – но как они выглядят изнутри? Для этого мы рассмотрим их работу на примере простого (очень простого) сетевого сервера aahzd, способного отвечать на запросы клиентов. Исходный код сервера представляет собой доработанный вариант открытого демонстрационного демона, написанного Давидом Жилье (David Gillies). 

Боровский А. Программирование для Unix [Текст] : Часть 8: Потоки: синхронизация / Андрей Боровский  //  Linux Format. — 2007. — № 1 (87-88), янв. — С. 72-75. — (Программирование для Unix. Учебник). 
     Аннотация
     Бесконтрольно размножающиеся потоки очень быстро устраивают соревнование за ресурсы системы. Андрей Боровский знает, как сделать так, чтобы все эти thread_func() не мешали друг другу. 

Боровский А. Программирование для Unix [Текст] : Часть 7: Потоки: создание и уничтожение / Андрей Боровский  //  Linux Format. — 2006. — № 12 (86), дек. — С. 71-75. — (Программирование для Unix. Учебник). 
     Аннотация
     Потоки и процессы в Linux – где та тонкая грань, что отличает одно от другого? 
     Жизненный цикл потоков – от создания до принудительного завершения. 
     Некоторые авторы избегают термина "поток" и используют вместо него термин "нить" (от англ. "thread"), вероятно для того, чтобы потоки программ не путались с потоками ввода-вывода. Для обозначения последовательного выполнения цепочки инструкций автору лично больше нравится термин "поток", которым он и пользуется, надеясь, что читатели Linux Format не запутаются в контекстах и, встретив слово поток, всегда поймут, идет ли речь о потоках программы, потоках ввода вывода, или о других потоках. 

Боровский А. Программирование для Unix [Текст] : Часть 6. Процессы и потоки / Андрей Боровский  //  Linux Format. — 2006. — № 11 (85), нояб. — С. 100-103. — (Программирование для Unix. Учебник). 
     Аннотация
     Понятие процесса и понимание управления процессами, программирование управления процессами в Linux. 

Боровский А. Программирование для Unix [Текст] : Часть 4. Сигналы / Андрей Боровский  //  Linux Format. — 2006. — № 10 (84), окт. — С. 90-93. — (Программирование для Unix. Учебник). — Библиогр.: с. 93 (2 назв.). — Прил.: "Поля структуры sigaction". — С. 92.
     Аннотация
     Сигналы традиционно считаются трудными в использовании, но при всем этом они незаменимы, когда речь заходит о настоящих приложениях Unix. 
     Рассматриваются только классические сигналы Unix, каковых в Linux насчитывается 31. Этим сигналам назначены номера с 1 до 31 (номер 0, так называемый null-сигнал, имеет особый смысл). Полный список сигналов можно получить из заголовочного файла signal.h. Рассмотрено несколько наиболее интересных сигналов.

Боровский А. Программирование для Unix [Текст] : Часть 3. Сокеты / Андрей Боровский  //  Linux Format. — 2006. — № 9 (83), сент. — С. 96-99. — (Учебник. Программирование для Unix). — Библиогр.: с. 99 (2 назв.). — Прил.: "Остроконечники и тупоконечники" : [Термины «little-endian» и «big-endian» (в компьютерной литературе обозначают порядок байтов, используемый процессором для представления простых многобайтовых типов): порядок байтов как проблема в компьютерном мире]". — С. 98.
     Аннотация
     При всем богатстве выбора средств взаимодействия между процессами в Unix/Linux, самыми популярными средствами были и остаются сокеты. Мы окунемся в мир сетевого программирования и познакомимся с сокетами – базовыми "кирпичиками", из которых строятся и мощные сервера, и легкие клиентские приложения.
     На этом наше знакомство с увлекательным миром межпроцессного взаимодействия Linux заканчивается. 

Боровский А. Программирование для Unix [Текст] : Часть 3. Очереди сообщений и семафоры / Андрей Боровский  //  Linux Format. — 2006. — № 8 (82), авг. — С. 102-105. — (Программирование для Unix. Учебник). — Библиогр.: с. 105 (3 назв.). — Прил.: "Неатомарность спин-блокировок" : [Операция «проверить значение – изменить значение» неатомарна, то есть ее выполнение может быть прервано другим процессом и алгоритм простых спин-блокировок (spin locks) не гарантирует надежного разграничения доступа и решение этой проблемы]". — С. 104.
     Аннотация
     Каналы – отнюдь не единственное средство IPC Unix/Linux. В этом выпуске Андрей Боровский рассказывает еще о нескольких механизмах межпроцессного взаимодействия, которые появились в Unix System V и были описаны в System V Interface Definition (SVID) — это сообщения и очереди сообщений, разделяемая память и семафоры (семафоры System V, семафоры POSIX и семафоры в разделяемой памяти).

Боровский А. Программирование для Unix [Текст] : Часть 2. Межпроцессное взаимодействие / Андрей Боровский  //  Linux Format. — 2006. — № 7 (81), июль. — С. 97-99. — (Программирование для Unix. Учебник). — Библиогр.: с. 99 (3 назв.). — Прил.: "Закон Брукса [критика]". — С. 97 ; "Как канал передает данные". — С. 98.
     Аннотация
     Возможность разграничения доступа к ресурсам очень полезна, но Linux не была бы настоящей многозадачной системой, если бы в ней не существовало простых и эффективных методов взаимодействия между процессами. Статья посвящена рассмотрению межпроцессного взаимодействия.
     Благодаря межпроцессному взаимодействию (Inter-Process Communication, IPC) разработчик (и пользователь) может разбить решение сложной задачи на несколько простых операций, каждая из которых доверяется отдельной небольшой программе. Последовательная обработка одной задачи несколькими простыми программами очень похожа на конвейерное производство (среди многих значений английского pipeline есть и "конвейер", но статье для перевода слова pipe используется принятый в отечественной литературе термин "канал".  

Боровский А. Программирование для Unix [Текст] : Часть 1. Linux API – работаем с файловой системой / Андрей Боровский  //  Linux Format. — 2006. — № 6 (80), июнь. — С. 92-95. — (Программирование для Unix. Учебник) (Программирование для Linux. Учебник). — Библиогр.: с. 95 (2 назв.). 
     Аннотация
     Файловая система Linux с точки зрения программиста: everything is a file или файлы – это наше все. 

Боровский А. Кодируем [Текст] : Cоветы бывалых / Андрей Боровский  //  Linux Format. — 2009. — № 4 (117), апр.. — С. 72-75. — (Программирование. Учебник) (Советы программистам. Учебник). — Прил.: "Переменные GNU Readline" : [Комментарии к переменным: set сompletion-ignore-case on, set completion-query-items n, set disable-completion on, set expand-tilde on, set mark-directories on, set match-hidden-files on, set print-completions-horizontally on, set show-all-if-ambiguous on, set visible-stats on]. — С. 73 ; "Скорая помощь. Перехват библиотечных вызовов полезен не только для отладки. Переопределив функции для работы с сокетами, вы можете перенаправить весь сетевой трафик приложения на выделенный SOCKS-сервер.". — С. 75. 
      Аннотация
      На протяжении многих лет Андрей Боровский собирал интересные фрагменты из исходных текстов разных популярных программ и из форумов, посвященных программированию для Unix. Подборкой тонкостей и хитростей программистского мастерства он делится с читателями Linux Format. 
      Мы узнаем: как реализовать в консольном приложении завершение имен команд и файлов по нажатию Tab и обогатить программу историей команд в стиле Bash при помощи библиотеки GNU Readline; как написать процедуру, заменяющую тильду именем домашнего каталога пользователя; как сразу после запуска заставить программу освободить окно консоли, из которого она запущена; как перехватить выполняемые программой вызовы библиотечных функций.