Nginx. Почему процессы, а не потоки?
======================================

 Когда делал веб-сервер (win api), я использовал потоки, чтобы обеспечить скорость работы на многоядерных системах.  
  

Nginx использует процессы, а не потоки. А почему?  
  
  

Собственно, есть несколько предположений, но понять какое из них верное, гугл не помог:  
  

1. Обойти лимит файловых дескрипторов на процесс.  
  

2. Отказоустойчивость (упал 1 процесс — другие живи).  
  

3. Безопасность (не уверен, что понимаю каким образом).  
  
  

Приму другие догадки, но лучше реальные причины такого решения, спасибо.  
  
Уточнение  
  

Потоки вместо процессов != один поток на одно соединение.   
  

Можно делать воркеры-процессы(nginx), можно воркеры-потоки(mywebserver), можно для каждого соединения создавать поток/процесс(apache).  
  
  

Интересует, конкретно, почему nginx напилил воркеры-**процессы**, а не воркеры-потоки.  
  
Ответ  
  

Игорь Сысоев:  
  
  

Изначально потоки планировались, но не были использованы по ряду причин:  
  
  

1) более трудоёмкое программирование,  
  

2) плохая поддержка потоков во FreeBSD и Linux на 2002-2004 год,  
  

3) процессы обеспечивают естественную изоляцию ресурсов, уменьшая  
  

конкуренцию за них. 

 Я думаю что это потому что FreeBSD, который использовался Rambler до недавнего времени и где работал Сысоев когда то давно, когда начинался nginx не мог балансировать потоки по процессорам. 

> Безопасность (не уверен, что понимаю каким образом)

  

Могу предположить, что в случае протоков мы имеем общее адресное пространство, что во-первых представляет потенциальную угрозу влияния одного потока на другой, а во вторых 4гб адресного пространства на 32-ти битной машине разделяются между всеми потоками, в то время как в случае процессов каждому процессу доступно 4гб. Соответственно решение с процессами более выгодно. 

 Псротой как тапок ответ — сам nginx может работать как с потоками, так и с процессами; но, к сожалению, заставить модули, включая и third-party модули работать thread-safe — не реально. Поэтому с процессами безопаснее и предсказуемее. 

 А с безопасностью совсем просто.  

На shared-хостинге натыкано 100500 юзеров, у каждого своя папка и свой конфиг сайта.  

Если каждый процесс nginx-a запущен с правами своего пользователя, то вся головная боль по допуску-недопуску одних юзеров в каталоги других юзеров лежит на ОС (и она с ней блестяще справляется). Если бы были потоки от одного-единственного юзера www-data, то ничего не мешало бы юзеру Пете сделать симлинк или просто ссылку в своём конфиге на папку юзера Васи и копаться в его файлах через веб-сервер. 

 Игорь Сысоев:  

  

Изначально потоки планировались, но не были использованы по ряду причин:  

  

1) более трудоёмкое программирование,  

2) плохая поддержка потоков во FreeBSD и Linux на 2002-2004 год,  

3) процессы обеспечивают естественную изоляцию ресурсов, уменьшая  

 конкуренцию за них. 

 Безопасность достигается тем, что головной процесс запускается от рута, воркеры от пользователя web-сервера (www-data в дебианоподобных). 

 В вышеупомянутой ссылке на вики написано:  

  

 — В серверах, построенных по модели «один поток на соединение», проблемы с масштабируемостью возникают по следующим причинам:  

  

слишком велики накладные расходы на структуры данных операционной системы, необходимые для описания одной задачи (сегмент состояния задачи, стек);  

 слишком велики накладные расходы на переключение контекстов.  

 — Разве это не ответ на ваш вопрос? 

 Тогда [habrahabr.ru/blogs/hi/108294/](http://habrahabr.ru/blogs/hi/108294/) ч.3 — там хорошо про взаимную блокировку потоков под нагрузкой расписано, даже с примером. 

 Имхо, потому что воркеры-процессы более просты в реализации и более обкатаны по времени. Но логичнее было бы спросить самого Игоря. 

 Может действительно стоит написать вопрос автору? Это точно прояснит ситуацию. 

[ru.wikipedia.org/wiki/Событийно-ориентированное\_программирование](http://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование)  

  

здесь есть и «почему» и минусы с плюсами 

 Написали бы сразу в рассылку nginx. 

 наверно потому что  

> nginx/Windows работает с Win32 API (не эмуляция Cygwin)В качестве метода обработки соединений используется select, поэтому не стоит ожидать высокой производительности и масштабируемости: пока это бета-версия.   
> 
>