В отличие от последовательного сервера, параллельный сервер обрабатывает более одного клиента в одно время. Например, чат сервер может обслуживать определённого клиента часами--сервер не может ждать пока он завершит обслуживание одного клиента перед тем, как начнёт обслуживать следующего.
Это требует серьёзного изменения в нашей блок-схеме:
Мы переместили serve из действий
процесса-даемона (daemon process) к
действиям его собственного процесса-сервера (server process). Так как каждый порождённый
процесс наследует все открытые файлы (сокет тоже считается файлом), то новый процесс
наследует не только сокет, созданный в
результате вызова accept
(accepted socket), но
также первоначально созданный сокет
(top socket), т.е. сокет, созданный главным процессом в начале выполнения программы.
Тем не менее, процесс-сервер не нуждается в этом сокете и может его немедленно закрыть. Похожим образом, процесс-даемон не нуждается в сокете, созданном в результате вызова accept, и не только может, но и обязан закрыть его, иначе у него рано или поздно закончатся файловые дескрипторы.
После того, как процесс-сервер
заканчивает обслуживание, он должен закрыть сокет, созданный в результате вызова accept. Вместо
возвращения к accept
, он завершается.
В UNIX® процесс выходит не в прямом смысле этого слова - он производит возврат к его родителю.
Типично, родительский процесс ожидает (функция wait
)
завершения порождённого процесса и получает возвращаемое значение. Тем не менее, наш
процесс-даемон не может просто
остановиться и ждать. Это бы помешало нашей цели создания дополнительных процессов. Но
если он никогда не будет ждать, то его дети станут зомби процессами, более не
функционирующими, но присутствующими в системе.
По этой причине процесс-даемон
нуждается в установке обработчиков
сигналов в фазе initialize
daemon. Как минимум, должна присутствовать обработка сигнала SIGHLD
, чтобы даемон могут удалять процессы зомби из системы и
освобождать ресурсы системы для дальнейшего использования.
Поэтому, наша блок-схема содержит пункт process signals, который не соединён ни с какими другими
пунктами. Многие серверы также обрабатывают SIGHUP
и
интерпретируют его, как команду от суперпользователя перечитать свои конфигурационные
файлы. Это позволяет нам изменять настройки без необходимости завершения и повторного
запуска этих серверов.
Пред. | Начало | След. |
Вспомогательные функции | Уровень выше | * IPv6 Internals |
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.