7.7. Параллельные серверы

В отличие от последовательного сервера, параллельный сервер обрабатывает более одного клиента в одно время. Например, чат сервер может обслуживать определённого клиента часами--сервер не может ждать пока он завершит обслуживание одного клиента перед тем, как начнёт обслуживать следующего.

Это требует серьёзного изменения в нашей блок-схеме:

Мы переместили serve из действий процесса-даемона (daemon process) к действиям его собственного процесса-сервера (server process). Так как каждый порождённый процесс наследует все открытые файлы (сокет тоже считается файлом), то новый процесс наследует не только сокет, созданный в результате вызова accept (accepted socket), но также первоначально созданный сокет (top socket), т.е. сокет, созданный главным процессом в начале выполнения программы.

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

После того, как процесс-сервер заканчивает обслуживание, он должен закрыть сокет, созданный в результате вызова accept. Вместо возвращения к accept, он завершается.

В UNIX® процесс выходит не в прямом смысле этого слова - он производит возврат к его родителю. Типично, родительский процесс ожидает (функция wait) завершения порождённого процесса и получает возвращаемое значение. Тем не менее, наш процесс-даемон не может просто остановиться и ждать. Это бы помешало нашей цели создания дополнительных процессов. Но если он никогда не будет ждать, то его дети станут зомби процессами, более не функционирующими, но присутствующими в системе.

По этой причине процесс-даемон нуждается в установке обработчиков сигналов в фазе initialize daemon. Как минимум, должна присутствовать обработка сигнала SIGHLD, чтобы даемон могут удалять процессы зомби из системы и освобождать ресурсы системы для дальнейшего использования.

Поэтому, наша блок-схема содержит пункт process signals, который не соединён ни с какими другими пунктами. Многие серверы также обрабатывают SIGHUP и интерпретируют его, как команду от суперпользователя перечитать свои конфигурационные файлы. Это позволяет нам изменять настройки без необходимости завершения и повторного запуска этих серверов.

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.