Shulou(Shulou.com)06/03 Report--

This article mainly introduces "detailed explanation of nginx event module structure". In daily operation, I believe many people have doubts about the detailed interpretation of nginx event module structure. The editor consulted all kinds of materials and sorted out simple and useful operation methods. I hope it will be helpful for you to answer the doubts about "detailed explanation of nginx event module structure"! Next, please follow the editor to study!

There are two main event core modules in nginx: ngx_events_module and ngx_event_core_module. The main difference between the two modules is that the type of ngx_events_module is NGX_CORE_MODULE, which is essentially a core module type, but it is a driving point of the event module, the parsed configuration item is events {}, and a structure is created to store the configuration related to the event module.

The type of ngx_event_core_module is NGX_EVENT_MODULE, and the basic configuration object of the event module is stored in the configuration object of this module, and its main function is to parse the child configuration items in the events {} configuration block.

Let's take a look at the basic configuration of these two modules.

1. Ngx_events_module

The following is the basic configuration of the ngx_events_module module:

Ngx_module_t ngx_events_module = {NGX_MODULE_V1, & ngx_events_module_ctx, / * module context * / ngx_events_commands, / * module directives * / NGX_CORE_MODULE, / * module type * / NULL, / * init master * / NULL / * init module * / NULL, / * init process * / NULL, / * init thread * / NULL, / * exit thread * / NULL / * exit process * / NULL, / * exit master * / NGX_MODULE_V1_PADDING} Static ngx_core_module_t ngx_events_module_ctx = {ngx_string ("events"), NULL, ngx_event_init_conf}; static ngx_command_t ngx_events_commands [] = {{ngx_string ("events"), NGX_MAIN_CONF | NGX_CONF_BLOCK | NGX_CONF_NOARGS, ngx_events_block, 0,0, NULL}, ngx_null_command}

In the definition of the ngx_events_module module, its module context points to ngx_events_module_ctx, the configuration of the second structure, while module directives points to ngx_events_commands, the definition of the third structure. As you can see, there is only one events configuration item defined in ngx_events_commands, and the type of this configuration item is NGX_CONF_BLOCK, that is, it is the type of configuration block. Here we understand that this command corresponds to the events {} configuration block we used in nginx.conf, and the parsing of this configuration block is done through the ngx_events_block () method.

We know that in the conf_ctx array in the core configuration object ngx_cycle_t of nginx, each module will have a configuration object in the corresponding position of the array. Similarly, the core module here will also have a configuration object, but the second attribute value in the second structure ngx_events_module_ctx above is NULL, that is to say, there is no method to create a configuration object in the definition of the event module here. But there is a way to initialize the configuration object, that is, the third property value ngx_event_init_conf () method.

So where is the configuration object for the event module created here?

In fact, it is done when parsing the configuration object, that is, in the execution of the ngx_events_block () method that parses the events {} configuration block. This method essentially creates an array of pointers and assigns it to the corresponding position of the conf_ctx of the ngx_cycle_t of the nginx core and the value object.

2. Ngx_event_core_module

Before we introduce the ngx_event_core_module module, we need to explain the interface definition of the event module:

Name of typedef struct {/ / event module ngx_str_t * name; / / before parsing the configuration item, this callback method is used to create the structure void * (* create_conf) (ngx_cycle_t * cycle) that stores the configuration item parameters. / / after parsing the configuration items, the init_conf () method will be called to comprehensively handle all configuration items of interest to the current event module char * (* init_conf) (ngx_cycle_t * cycle, void * conf); / / for event-driven mechanisms, 10 abstract methods ngx_event_actions_t actions;} ngx_event_module_t that each event module needs to implement Typedef struct {/ / add an event method, which is responsible for adding an event of interest to the event-driven mechanism provided by the operating system (epoll, kqueue, etc.). / / in this way, after the event occurs, you can get the event ngx_int_t (* add) (ngx_event_t * ev, ngx_int_t event, ngx_uint_t flags) when calling the following process_events / / Delete the event method, which removes an event that already exists in the event-driven mechanism, so that even if the event occurs later, the event ngx_int_t (* del) (ngx_event_t * ev, ngx_int_t event, ngx_uint_t flags) can no longer be obtained when the process_events () method is called. / / enable an event, which is not currently called by the event framework. Most event-driven modules implement this method with ngx_int_t (* enable) (ngx_event_t * ev, ngx_int_t event, ngx_uint_t flags) that is exactly the same as the above add () method. / / disable an event, which is not currently called by the event framework. Most event-driven modules implement this method with ngx_int_t (* disable) (ngx_event_t * ev, ngx_int_t event, ngx_uint_t flags) that is exactly the same as the above del () method. / / add a new connection to the event-driven mechanism, which means that all read-write events on the connection are added to the event-driven mechanism ngx_int_t (* add_conn) (ngx_connection_t * c); / / remove a connected read-write event ngx_int_t (* del_conn) (ngx_connection_t * c, ngx_uint_t flags) from the event-driven mechanism Ngx_int_t (* notify) (ngx_event_handler_pt handler); / / in a normal work cycle, events are handled by calling the process_events () method. / / this method is only called in the ngx_process_events_and_timers () method. It is the core ngx_int_t (* process_events) (ngx_cycle_t * cycle, ngx_msec_t timer, ngx_uint_t flags) that handles and distributes events; / / the method ngx_int_t (* init) (ngx_cycle_t * cycle, ngx_msec_t timer) that initializes the event-driven module. / / the method void (* done) (ngx_cycle_t * cycle) called before exiting the event-driven module;} ngx_event_actions_t

The event module of nginx has two main configuration structures: ngx_event_module_t and ngx_event_actions_t. As you can see from the above definition, the ngx_event_module_t structure refers to ngx_event_actions_t.

The main function of ngx_event_module_t is to create and initialize the configuration structure needed by the current module, while ngx_event_actions_t mainly defines how the current event module handles each event. The typical implementation interface of this interface is each event model defined by nginx, such as epoll's ngx_epoll_module_ctx.actions and kqueue's ngx_kqueue_module_ctx.actions. From this, we can see that the definition of the event module abstracts the relevant processing methods of each model that handles the event.

As far as the event module is concerned, one module is used to store the basic configuration related to the event, namely ngx_event_core_module, although it implements the ngx_event_module_t interface, but it does not handle specific events. The following is the definition of the ngx_event_core_module module:

Ngx_module_t ngx_event_core_module = {NGX_MODULE_V1, & ngx_event_core_module_ctx, / * module context * / ngx_event_core_commands, / * module directives * / NGX_EVENT_MODULE, / * module type * / NULL / * init master * / / this method is mainly called during the startup of the master process Used to initialize the time module ngx_event_module_init, / * init module * / / this method is the ngx_event_process_init called after each worker process is started, / * init process * / NULL, / * init thread * / NULL / * exit thread * / NULL, / * exit process * / NULL, / * exit master * / NGX_MODULE_V1_PADDING} Static ngx_event_module_t ngx_event_core_module_ctx = {& event_core_name, ngx_event_core_create_conf, / * create configuration * / ngx_event_core_init_conf, / * init configuration * / / ngx_event_core_module_ctx is not directly responsible for driving TCP network events / / so the methods in ngx_event_actions_t here are all NULL {NULL, NULL}} Static ngx_command_t ngx_event_core_commands [] = {/ / the size of the connection pool, that is, the maximum number of TCP connections supported per worker process Its meaning with the connections configuration item is repeated {ngx_string ("worker_connections"), NGX_EVENT_CONF | NGX_CONF_TAKE1, ngx_event_connections, 0,0, NULL}, / / to determine which event module is selected as the event-driven mechanism {ngx_string ("use"), NGX_EVENT_CONF | NGX_CONF_TAKE1, ngx_event_use, 0,0 NULL}, / / corresponds to the available attribute in ngx_event_s For epoll event-driven mode, it means that when a new connection event is received / / call accept to receive as many connections as possible {ngx_string ("multi_accept"), NGX_EVENT_CONF | NGX_CONF_FLAG, ngx_conf_set_flag_slot, 0, offsetof (ngx_event_conf_t, multi_accept), NULL}, / / determine whether to use accept_mutex load balancer lock Default is to enable {ngx_string ("accept_mutex"), NGX_EVENT_CONF | NGX_CONF_FLAG, ngx_conf_set_flag_slot, 0, offsetof (ngx_event_conf_t, accept_mutex), NULL}, / / enable accept_mutex load balancer lock Delay accept_mutex_delay milliseconds before attempting to process new connection events {ngx_string ("accept_mutex_delay"), NGX_EVENT_CONF | NGX_CONF_TAKE1, ngx_conf_set_msec_slot, 0, offsetof (ngx_event_conf_t, accept_mutex_delay), NULL}, / / you need to print debug-level debug log {ngx_string ("debug_connection") for TCP connections from the specified IP. NGX_EVENT_CONF | NGX_CONF_TAKE1, ngx_event_debug_connection, 0,0, NULL}, ngx_null_command}

In the definition of the event module, module context points to a ngx_event_module_t structure, where the module context of ngx_event_core_module points to the ngx_event_core_module_ctx defined by the second structure, while ngx_event_core_module_ctx defines the methods for the current core module to create and initialize configuration objects. You can see that the values in its actions attribute are all NULL. This is because the module is not responsible for dealing with the specific event handling scheme, but is responsible for the creation and initialization of the core structure. Nginx will also ensure that this module is called first among all event modules, and the other event modules can also reference the basic configuration data stored by the module.

The third property, ngx_event_core_commands, in ngx_event_core_module points to the third structure above, which defines the basic configuration of each configuration item that can be used by the current event module and how to parse these configuration items.

Here we need to emphasize the sixth and seventh attributes in ngx_event_core_module, which point to a certain method. The sixth property, init module, is mainly executed after parsing the nginx.conf configuration file during nginx startup, and its function is to initialize the current module, while the seventh attribute init process is mainly called after the nginx starts the worker process before the worker process begins to execute the main loop. Its function is to initialize the worker process before execution.

3. Execution flow of module method

Through the above introduction, we have a general understanding of the main methods and functions of the two core modules that define the event module. Here, we mainly explain the execution process of these methods, as follows:

For the above, you need to explain the function of each step:

1. Parse the nginx.conf file, and when you encounter an events configuration item, parse it using the ngx_evetns_block () method

two。 Create an array of structures used to store each event module storage configuration item

3. Parse the sub-configuration items in the events configuration block recursively

4. Check the configuration items of the event core module in turn, and assign a default value to it if it is not assigned

5. Check whether an array of event module configuration items has been created. The main purpose of this check is to determine whether the core module has been initialized successfully.

6. It mainly sets the configuration items obtained by parsing, such as the execution frequency of the time timer, the restrictions on the file handles that can be opened, and the properties that initialize the record statistics.

7. Called in the worker process to initialize the environment needed for the worker process to run, such as initializing the event queue, initializing the event model, adding scheduled tasks for time updates, etc.

At this point, the study of "detailed explanation of the structure of nginx event module" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.