Re: Где лучше всего хранить состояние модуля?

[Sergey Zhemzhitsky]

Так, вроде бы разобрался.

init_process действительно то, что нужно.

Спасибо!

> Максим, большое спасибо за комментарии!

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

> А не подскажете, где лучше всего это делать.
> По исходникам и экспериментам, похоже, что callback init_process
> срабатывает как раз внутри воркера.


>> Hello!

>> On Mon, Mar 04, 2013 at 08:29:00AM +0400, Sergey Zhemzhitsky wrote:

>>> Привет, Nginx Гуру
>>> 
>>> Модули к nginx никогда не разрабатывал, поэтому не пинайте сильно.
>>> 
>>> Я пытаюсь написать nginx http-модуль к сторонней системе у которой есть С API.
>>> Под этим API лежит в том чесле и установка TCP/IP соединения.
>>> 
>>> Насколько я понял, правильным способом подключения к сторонней системе была бы разработка unstream http модуля.
>>> Проблема в том, что протокол довольно сложный и в условиях ограниченного времени разбираться с ним некогда,
>>> поэтому хотелось бы попользовать API, которое предоставляет система.
>>> 
>>> Посоветуйте, плиз, по следующим вопросам
>>> 
>>> 1. Где лучше всего хранить объекты, которые должны быть созданы и инициализированы только один раз для куска конфигурации
>>> server или http?
>>> 2. Где лучше всего создавать объекты, которые должны присутствовать единожды для конфигурации server или http (например,
>>> устанавливать соединение со сторонней системой)?
>>> 3. Насколько я понял под upstream-ами *всегда* лежит асинхронное сокетное api. Верно?
>>> 4. Насколько плохо работать напрямую со своими TPC/IP соединениями прямо из request handler-ов?

>> In no particular order:

>> 1. Конфигурацию модуля, а также глобальные сущности с ней связанные - 
>> правильнее всего хранить в, как это ни странно, конфиге модуля.

>> Надо, однако, иметь ввиду, что конфиг создаётся в master-процессе, 
>> а потом при fork()'е наследуется в worker'ов.  Так что если вы 
>> там, e.g., хотите создавать постоянные соединения с бекендом - то 
>> делать это надо уже после старта рабочих процессов в них самих, а 
>> не при чтении конфига.

>> 2. Таки да, nginx - event-based сервер, и для работы со всем чем 
>> можно - используются event-based API.

>> 3. Upstream - это точно такой же модуль, как и все остальные.  
>> Если вы хотите написать свой модуль, аналогичный upstream'у, я бы 
>> рекомендовал для начала посмотреть на upstream.

>> 4. Работать с сокетами из request handler'ов - не плохо.  Работать 
>> с ними в блокирующемся режиме - плохая идея.