Предварительное создание ведомых процессов и потоков в системе Linux
Такие операционные системы, как Linux, в которых предусмотрена поддержка потоков, упрощают взаимодействие между ведущим потоком и предварительно созданными ведомыми потоками, поскольку ведущий поток и ведомые потоки могут совместно использовать память. Даже если ведомые компоненты функционируют как отдельные процессы, не имеющие общей памяти с ведущим процессом, предварительное создание процессов остается осуществимым. Координация работы между процессами выполняется через разделяемые сокеты.
После вызова в процессе функции fork вновь созданный дочерний процесс получает копию всех открытых дескрипторов, включая те из них, что соответствуют сокетам.
Для обеспечения возможности совместного использования сокета ведущий процесс открывает необходимый сокет перед предварительным созданием ведомых процессов. В частности, ведущий процесс сервера после запуска открывает сокет для общепринятого порта, через который будут поступать запросы. Затем ведущий процесс вызывает функцию fork для создания необходимого числа ведомых процессов. Поскольку каждый процесс получает все копии дескрипторов сокетов от родительского, все ведомые процессы имеют доступ к сокету общепринятого порта. В следующих разделах приведены подробные сведения об использовании метода предварительного создания в серверах с установлением и без установления логического соединения. газовые водонагреватели накопительные
16.8.2. Применение метода предварительного создания в сервере с установлением логического соединения
Если в параллельном сервере для связи используется протокол TCP, то степень распараллеливания зависит от числа активных соединений. Каждый входящий запрос на установление соединения должен быть обработан независимым процессом. К счастью, в системе Linux предусмотрена возможность применения мьютекса для координации работы нескольких процессов, одновременно пытающихся получить доступ к соединению в одном и том же сокете. Каждый ведомый процесс вызывает функцию accept, которая блокируется в ожидании поступления входящего запроса на установление соединения через общепринятый порт. После поступления запроса на установление соединения операционная система разблокирует один и только один из ведомых процессов. В отдельном ведомом процессе после возврата управления функция accept предоставляет новый дескриптор файла для входящего соединения. Ведомый процесс обслуживает соединение, закрывает новый сокет, а затем вызывает функцию accept для перехода в состояние ожидания следующего запроса. Схема организации процессов показана на рис. 16.2. В этом примере показано три предварительно созданных ведомых процессах, но лишь один из них фактически обслуживает соединение. Ведущий процесс открывает сокет для общепринятого порта, но не использует его.
Как показано на этом рисунке, все ведомые процессы наследуют права доступа к сокету для общепринятого порта. Каждый отдельный ведомый процесс получает новый сокет для отдельного соединения после возврата управления из функции accept. Хотя ведущий процесс создает сокет, соответствующий общепринятому порту, он не использует сокет для выполнения каких-либо дальнейших действий. Пунктирная линия на этом рисунке обозначает, где заканчивается использование сокета ведущим процессом и начинается его использование ведомыми процессами.
Хотя рис. 16.2 показывает, что ведущий процесс функционирует одновременно с ведомыми, он также подчеркивает, что разница между ведущим и ведомым процессами при такой организации работы становится более размытой. По существу, ведущий процесс после предварительного создания ведомых процессов больше не выполняет никаких функций. Поэтому ведущий процесс может просто завершить свою работу после запуска всех ведомых процессов. В остроумной программе можно было бы даже предусмотреть создание ведущим процессом всех ведомых процессов, кроме последнего. Затем ведущий процесс может стать последним ведомым процессом и сэкономить тем самым затраты на создание еще одного процесса. В системе Linux для выполнения такого действия требуется простейший код.