Основной поток блокируется в вызове функции accept, и каждый раз, когда прибывает новое клиентское соединение, функцией
pthread_create
создается новый поток. Функция, выполняемая новым потоком, — это функция
doit
, а ее аргументом является присоединенный сокет.
Функция прочих потоков
25-33
Функция
doit
выполняется как отсоединенный (detached) поток, потому что основному потоку не требуется ждать ее завершения.
Doit
вызывает функцию
web_child
(см. листинг 30.5). Когда эта функция возвращает управление, присоединенный сокет закрывается.
Из табл. 30.1 мы видим, что эта простая версия с использованием потоков является более быстродействующей, чем даже самая быстрая из версий с предварительным порождением процессов. Кроме того, эта версия, в которой каждый клиент обслуживается одним потоком, во много раз быстрее версии, в которой каждый клиент обслуживается специально созданным для него дочерним процессом (первая строка табл. 30.1).
ПРИМЕЧАНИЕ
В разделе 26.5 мы упомянули о трех вариантах преобразования функции, которая не является безопасной в многопоточной среде, в функцию, обеспечивающую требуемую безопасность. Функция web_child вызывает функцию readline, и версия, показанная в листинге 3.12, не является безопасной в многопоточной среде. На примере, приведенном в листинге 30.20, были испробованы вторая и третья альтернативы из раздела 26.5. Увеличение быстродействия при переходе от альтернативы 3 к альтернативе 2 составило менее одного процента, вероятно, потому, что функция readline использовалась лишь для считывания значения счетчика (5 символов) от клиента. Поэтому в данной главе для простоты мы использовали более медленную версию из листинга 3.11 для сервера
с предварительным порождением потоков.
30.11. Сервер TCP с предварительным порождением потоков, каждый из которых вызывает accept
Ранее в этой главе мы обнаружили, что версии, в которых заранее создается пул дочерних процессов, работают быстрее, чем те, в которых для каждого клиентского запроса приходится вызывать функцию
fork
. Для систем, поддерживающих потоки, логично предположить, что имеется та же закономерность: быстрее сразу создать пул потоков при запуске сервера, чем создавать по одному потоку по мере поступления запросов от клиентов. Основная идея такого сервера заключается в том, чтобы создать пул потоков, каждый из которых вызывает затем функцию
accept
. Вместо того чтобы блокировать потоки в вызове
accept
, мы используем взаимное исключение, как в разделе 30.8. Это позволяет вызывать функцию accept только одному потоку в каждый момент времени. Использовать блокировку файла для защиты
accept
в таком случае бессмысленно, так как при наличии нескольких потоков внутри данного процесса можно использовать взаимное исключение.
В листинге 30.21 показан заголовочный файл
pthread07.h
, определяющий структуру
Thread
, содержащую определенную информацию о каждом потоке.
3 long thread_count; /* количество обработанных запросов */
4 } Thread;
5 Thread *tptr; /* массив структур Thread */
6 int listenfd, nthreads;
7 socklen_t addrlen;
8 pthread_mutex_t mlock;
Мы также объявляем несколько глобальных переменных, таких как дескриптор прослушиваемого сокета и взаимное исключение, которые должны совместно использоваться всеми потоками.
В листинге 30.22 показана функция
main
.
Листинг 30.22. Функция main для сервера TCP с предварительным порождением потоков