|
1899
|
1 <?xml version="1.0"?>
|
|
|
2
|
|
|
3 <!--
|
|
|
4 Copyright (C) Nginx, Inc.
|
|
|
5 -->
|
|
|
6
|
|
|
7 <!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
|
|
|
8
|
|
|
9 <article name="Development guide"
|
|
|
10 link="/en/docs/dev/development_guide.html"
|
|
|
11 lang="en"
|
|
|
12 rev="1">
|
|
|
13
|
|
|
14 <section name="Introduction" id="introduction">
|
|
|
15
|
|
|
16
|
|
|
17 <section name="Code layout" id="code_layout">
|
|
|
18
|
|
|
19 <para>
|
|
|
20 <list type="bullet">
|
|
|
21 <listitem>
|
|
|
22 <literal>auto</literal> - build scripts
|
|
|
23 </listitem>
|
|
|
24
|
|
|
25 <listitem>
|
|
|
26 <literal>src</literal>
|
|
|
27
|
|
|
28 <list type="bullet">
|
|
|
29
|
|
|
30 <listitem>
|
|
|
31 <literal>core</literal> - basic types and functions - string, array, log,
|
|
|
32 pool etc
|
|
|
33 </listitem>
|
|
|
34
|
|
|
35 <listitem>
|
|
|
36 <literal>event</literal> - event core
|
|
|
37
|
|
|
38 <list type="bullet">
|
|
|
39
|
|
|
40 <listitem>
|
|
|
41 <literal>modules</literal> - event notification modules: epoll, kqueue,
|
|
|
42 select etc
|
|
|
43 </listitem>
|
|
|
44
|
|
|
45 </list>
|
|
|
46
|
|
|
47 </listitem>
|
|
|
48
|
|
|
49 <listitem>
|
|
|
50 <literal>http</literal> - core HTTP module and common code
|
|
|
51
|
|
|
52 <list type="bullet">
|
|
|
53
|
|
|
54 <listitem>
|
|
|
55 <literal>modules</literal> - other HTTP modules
|
|
|
56 </listitem>
|
|
|
57
|
|
|
58 <listitem>
|
|
|
59 <literal>v2</literal> - HTTPv2
|
|
|
60 </listitem>
|
|
|
61
|
|
|
62 </list>
|
|
|
63
|
|
|
64 </listitem>
|
|
|
65
|
|
|
66 <listitem>
|
|
|
67 <literal>mail</literal> - mail modules
|
|
|
68 </listitem>
|
|
|
69
|
|
|
70 <listitem>
|
|
|
71 <literal>os</literal> - platform-specific code
|
|
|
72
|
|
|
73 <list type="bullet">
|
|
|
74
|
|
|
75 <listitem>
|
|
|
76 <literal>unix</literal>
|
|
|
77 </listitem>
|
|
|
78
|
|
|
79 <listitem>
|
|
|
80 <literal>win32</literal>
|
|
|
81 </listitem>
|
|
|
82
|
|
|
83 </list>
|
|
|
84
|
|
|
85 </listitem>
|
|
|
86
|
|
|
87 <listitem>
|
|
|
88 <literal>stream</literal> - stream modules
|
|
|
89 </listitem>
|
|
|
90
|
|
|
91 </list>
|
|
|
92
|
|
|
93 </listitem>
|
|
|
94
|
|
|
95 </list>
|
|
|
96 </para>
|
|
|
97
|
|
|
98 </section>
|
|
|
99
|
|
|
100
|
|
|
101 <section name="Include files" id="include_files">
|
|
|
102
|
|
|
103 <para>
|
|
|
104 Each nginx file should start with including the following two files:
|
|
|
105 </para>
|
|
|
106
|
|
|
107
|
|
|
108 <programlisting>
|
|
|
109 #include <ngx_config.h>
|
|
|
110 #include <ngx_core.h>
|
|
|
111 </programlisting>
|
|
|
112
|
|
|
113 <para>
|
|
|
114 In addition to that, HTTP code should include
|
|
|
115 </para>
|
|
|
116
|
|
|
117
|
|
|
118 <programlisting>
|
|
|
119 #include <ngx_http.h>
|
|
|
120 </programlisting>
|
|
|
121
|
|
|
122 <para>
|
|
|
123 Mail code should include
|
|
|
124 </para>
|
|
|
125
|
|
|
126
|
|
|
127 <programlisting>
|
|
|
128 #include <ngx_mail.h>
|
|
|
129 </programlisting>
|
|
|
130
|
|
|
131 <para>
|
|
|
132 Stream code should include
|
|
|
133 </para>
|
|
|
134
|
|
|
135
|
|
|
136 <programlisting>
|
|
|
137 #include <ngx_stream.h>
|
|
|
138 </programlisting>
|
|
|
139
|
|
|
140 </section>
|
|
|
141
|
|
|
142
|
|
|
143 <section name="Integers" id="integers">
|
|
|
144
|
|
|
145 <para>
|
|
|
146 For general purpose, nginx code uses the following two integer types
|
|
|
147 <literal>ngx_int_t</literal> and <literal>ngx_uint_t</literal> which are
|
|
|
148 typedefs for <literal>intptr_t</literal> and <literal>uintptr_t</literal>.
|
|
|
149 </para>
|
|
|
150
|
|
|
151 </section>
|
|
|
152
|
|
|
153
|
|
|
154 <section name="Common return codes" id="common_return_codes">
|
|
|
155
|
|
|
156 <para>
|
|
|
157 Most functions in nginx return the following codes:
|
|
|
158 </para>
|
|
|
159
|
|
|
160 <para>
|
|
|
161 <list type="bullet">
|
|
|
162
|
|
|
163 <listitem>
|
|
|
164 <literal>NGX_OK</literal> - operation succeeded
|
|
|
165 </listitem>
|
|
|
166
|
|
|
167 <listitem>
|
|
|
168 <literal>NGX_ERROR</literal> - operation failed
|
|
|
169 </listitem>
|
|
|
170
|
|
|
171 <listitem>
|
|
|
172 <literal>NGX_AGAIN</literal> - operation incomplete, function should be called
|
|
|
173 again
|
|
|
174 </listitem>
|
|
|
175
|
|
|
176 <listitem>
|
|
|
177 <literal>NGX_DECLINED</literal> - operation rejected, for example, if disabled
|
|
|
178 in configuration. This is never an error
|
|
|
179 </listitem>
|
|
|
180
|
|
|
181 <listitem>
|
|
|
182 <literal>NGX_BUSY</literal> - resource is not available
|
|
|
183 </listitem>
|
|
|
184
|
|
|
185 <listitem>
|
|
|
186 <literal>NGX_DONE</literal> - operation done or continued elsewhere.
|
|
|
187 Also used as an alternative success code
|
|
|
188 </listitem>
|
|
|
189
|
|
|
190 <listitem>
|
|
|
191 <literal>NGX_ABORT</literal> - function was aborted.
|
|
|
192 Also used as an alternative error code
|
|
|
193 </listitem>
|
|
|
194
|
|
|
195 </list>
|
|
|
196 </para>
|
|
|
197
|
|
|
198 </section>
|
|
|
199
|
|
|
200
|
|
|
201 <section name="Error handling" id="error_handling">
|
|
|
202
|
|
|
203 <para>
|
|
|
204 For getting the last system error code, the <literal>ngx_errno</literal> macro
|
|
|
205 is available.
|
|
|
206 It's mapped to <literal>errno</literal> on POSIX platforms and to
|
|
|
207 <literal>GetLastError()</literal> call in Windows.
|
|
|
208 For getting the last socket error number, the
|
|
|
209 <literal>ngx_socket_errno</literal> macro is available.
|
|
|
210 It's mapped to <literal>errno</literal> on POSIX systems as well,
|
|
|
211 and to <literal>WSAGetLastError()</literal> call on Windows.
|
|
|
212 For performance reasons the values of <literal>ngx_errno</literal> or
|
|
|
213 <literal>ngx_socket_errno</literal> should not be accessed more than
|
|
|
214 once in a row.
|
|
|
215 The error value should be stored in a local variable of type
|
|
|
216 <literal>ngx_err_t</literal> for using multiple times, if required.
|
|
|
217 For setting errors, <literal>ngx_set_errno(errno)</literal> and
|
|
|
218 <literal>ngx_set_socket_errno(errno)</literal> macros are available.
|
|
|
219 </para>
|
|
|
220
|
|
|
221 <para>
|
|
|
222 The values of <literal>ngx_errno</literal> or
|
|
|
223 <literal>ngx_socket_errno</literal> can be passed to logging functions
|
|
|
224 <literal>ngx_log_error()</literal> and <literal>ngx_log_debugX()</literal>, in
|
|
|
225 which case system error text is added to the log message.
|
|
|
226 </para>
|
|
|
227
|
|
|
228 <para>
|
|
|
229 Example using <literal>ngx_errno</literal>:
|
|
|
230 </para>
|
|
|
231
|
|
|
232
|
|
|
233 <programlisting>
|
|
|
234 void
|
|
|
235 ngx_my_kill(ngx_pid_t pid, ngx_log_t *log, int signo)
|
|
|
236 {
|
|
|
237 ngx_err_t err;
|
|
|
238
|
|
|
239 if (kill(pid, signo) == -1) {
|
|
|
240 err = ngx_errno;
|
|
|
241
|
|
|
242 ngx_log_error(NGX_LOG_ALERT, log, err, "kill(%P, %d) failed", pid, signo);
|
|
|
243
|
|
|
244 if (err == NGX_ESRCH) {
|
|
|
245 return 2;
|
|
|
246 }
|
|
|
247
|
|
|
248 return 1;
|
|
|
249 }
|
|
|
250
|
|
|
251 return 0;
|
|
|
252 }
|
|
|
253 </programlisting>
|
|
|
254
|
|
|
255 </section>
|
|
|
256
|
|
|
257
|
|
|
258 </section>
|
|
|
259
|
|
|
260
|
|
|
261 <section name="Strings" id="strings">
|
|
|
262
|
|
|
263
|
|
|
264 <section name="Overview" id="overview">
|
|
|
265
|
|
|
266 <para>
|
|
|
267 For C strings, nginx code uses unsigned character type pointer
|
|
|
268 <literal>u_char *</literal>.
|
|
|
269 </para>
|
|
|
270
|
|
|
271 <para>
|
|
|
272 The nginx string type <literal>ngx_str_t</literal> is defined as follows:
|
|
|
273 </para>
|
|
|
274
|
|
|
275
|
|
|
276 <programlisting>
|
|
|
277 typedef struct {
|
|
|
278 size_t len;
|
|
|
279 u_char *data;
|
|
|
280 } ngx_str_t;
|
|
|
281 </programlisting>
|
|
|
282
|
|
|
283 <para>
|
|
|
284 The <literal>len</literal> field holds the string length,
|
|
|
285 <literal>data</literal> holds the string data.
|
|
|
286 The string, held in <literal>ngx_str_t</literal>, may or may not be
|
|
|
287 null-terminated after the <literal>len</literal> bytes.
|
|
|
288 In most cases it’s not.
|
|
|
289 However, in certain parts of code (for example, when parsing configuration),
|
|
|
290 <literal>ngx_str_t</literal> objects are known to be null-terminated, and that
|
|
|
291 knowledge is used to simplify string comparison and makes it easier to pass
|
|
|
292 those strings to syscalls.
|
|
|
293 </para>
|
|
|
294
|
|
|
295 <para>
|
|
|
296 A number of string operations are provided in nginx.
|
|
|
297 They are declared in <literal>src/core/ngx_string.h</literal>.
|
|
|
298 Some of them are wrappers around standard C functions:
|
|
|
299 </para>
|
|
|
300
|
|
|
301 <para>
|
|
|
302 <list type="bullet">
|
|
|
303
|
|
|
304 <listitem>
|
|
|
305 <literal>ngx_strcmp()</literal>
|
|
|
306 </listitem>
|
|
|
307
|
|
|
308 <listitem>
|
|
|
309 <literal>ngx_strncmp()</literal>
|
|
|
310 </listitem>
|
|
|
311
|
|
|
312 <listitem>
|
|
|
313 <literal>ngx_strstr()</literal>
|
|
|
314 </listitem>
|
|
|
315
|
|
|
316 <listitem>
|
|
|
317 <literal>ngx_strlen()</literal>
|
|
|
318 </listitem>
|
|
|
319
|
|
|
320 <listitem>
|
|
|
321 <literal>ngx_strchr()</literal>
|
|
|
322 </listitem>
|
|
|
323
|
|
|
324 <listitem>
|
|
|
325 <literal>ngx_memcmp()</literal>
|
|
|
326 </listitem>
|
|
|
327
|
|
|
328 <listitem>
|
|
|
329 <literal>ngx_memset()</literal>
|
|
|
330 </listitem>
|
|
|
331
|
|
|
332 <listitem>
|
|
|
333 <literal>ngx_memcpy()</literal>
|
|
|
334 </listitem>
|
|
|
335
|
|
|
336 <listitem>
|
|
|
337 <literal>ngx_memmove()</literal>
|
|
|
338 </listitem>
|
|
|
339
|
|
|
340 </list>
|
|
|
341
|
|
|
342 </para>
|
|
|
343
|
|
|
344 <para>
|
|
|
345 Some nginx-specific string functions:
|
|
|
346 </para>
|
|
|
347
|
|
|
348 <para>
|
|
|
349 <list type="bullet">
|
|
|
350
|
|
|
351 <listitem>
|
|
|
352 <literal>ngx_memzero()</literal> fills memory with zeroes
|
|
|
353 </listitem>
|
|
|
354
|
|
|
355 <listitem>
|
|
|
356 <literal>ngx_cpymem()</literal> does the same as
|
|
|
357 <literal>ngx_memcpy()</literal>, but returns the final destination address
|
|
|
358 This one is handy for appending multiple strings in a row
|
|
|
359 </listitem>
|
|
|
360
|
|
|
361 <listitem>
|
|
|
362 <literal>ngx_movemem()</literal> does the same as
|
|
|
363 <literal>ngx_memmove()</literal>, but returns the final destination address.
|
|
|
364 </listitem>
|
|
|
365
|
|
|
366 <listitem>
|
|
|
367 <literal>ngx_strlchr()</literal> searches for a character in a string,
|
|
|
368 delimited by two pointers
|
|
|
369 </listitem>
|
|
|
370 </list>
|
|
|
371 </para>
|
|
|
372
|
|
|
373 <para>
|
|
|
374 Some case conversion and comparison functions:
|
|
|
375 </para>
|
|
|
376
|
|
|
377 <para>
|
|
|
378 <list type="bullet">
|
|
|
379
|
|
|
380 <listitem>
|
|
|
381 <literal>ngx_tolower()</literal>
|
|
|
382 </listitem>
|
|
|
383
|
|
|
384 <listitem>
|
|
|
385 <literal>ngx_toupper()</literal>
|
|
|
386 </listitem>
|
|
|
387
|
|
|
388 <listitem>
|
|
|
389 <literal>ngx_strlow()</literal>
|
|
|
390 </listitem>
|
|
|
391
|
|
|
392 <listitem>
|
|
|
393 <literal>ngx_strcasecmp()</literal>
|
|
|
394 </listitem>
|
|
|
395
|
|
|
396 <listitem>
|
|
|
397 <literal>ngx_strncasecmp()</literal>
|
|
|
398 </listitem>
|
|
|
399
|
|
|
400 </list>
|
|
|
401 </para>
|
|
|
402
|
|
|
403 </section>
|
|
|
404
|
|
|
405
|
|
|
406 <section name="Formatting" id="formatting">
|
|
|
407
|
|
|
408 <para>
|
|
|
409 A number of formatting functions are provided by nginx. These functions support nginx-specific types:
|
|
|
410 </para>
|
|
|
411
|
|
|
412
|
|
|
413 <para>
|
|
|
414 <list type="bullet">
|
|
|
415
|
|
|
416 <listitem>
|
|
|
417 <literal>ngx_sprintf(buf, fmt, ...)</literal>
|
|
|
418 </listitem>
|
|
|
419
|
|
|
420 <listitem>
|
|
|
421 <literal>ngx_snprintf(buf, max, fmt, ...)</literal>
|
|
|
422 </listitem>
|
|
|
423
|
|
|
424 <listitem>
|
|
|
425 <literal>ngx_slrintf(buf, last, fmt, ...)</literal>
|
|
|
426 </listitem>
|
|
|
427
|
|
|
428 <listitem>
|
|
|
429 <literal>ngx_vslprint(buf, last, fmt, args)</literal>
|
|
|
430 </listitem>
|
|
|
431
|
|
|
432 <listitem>
|
|
|
433 <literal>ngx_vsnprint(buf, max, fmt, args)</literal>
|
|
|
434 </listitem>
|
|
|
435
|
|
|
436 </list>
|
|
|
437 </para>
|
|
|
438
|
|
|
439 <para>
|
|
|
440 The full list of formatting options, supported by these functions, can be found
|
|
|
441 in <literal>src/core/ngx_string.c</literal>. Some of them are:
|
|
|
442 </para>
|
|
|
443
|
|
|
444
|
|
|
445 <programlisting>
|
|
|
446 %O - off_t
|
|
|
447 %T - time_t
|
|
|
448 %z - size_t
|
|
|
449 %i - ngx_int_t
|
|
|
450 %p - void *
|
|
|
451 %V - ngx_str_t *
|
|
|
452 %s - u_char * (null-terminated)
|
|
|
453 %*s - size_t + u_char *
|
|
|
454 </programlisting>
|
|
|
455
|
|
|
456 <para>
|
|
|
457 The ‘u’ modifier makes most types unsigned, ‘X’/‘x’ convert output to hex.
|
|
|
458 </para>
|
|
|
459
|
|
|
460 <para>
|
|
|
461 Example:
|
|
|
462
|
|
|
463 <programlisting>
|
|
|
464 u_char buf[NGX_INT_T_LEN];
|
|
|
465 size_t len;
|
|
|
466 ngx_int_t n;
|
|
|
467
|
|
|
468 /* set n here */
|
|
|
469
|
|
|
470 len = ngx_sprintf(buf, "%ui", n) - buf;
|
|
|
471 </programlisting>
|
|
|
472
|
|
|
473 </para>
|
|
|
474
|
|
|
475 </section>
|
|
|
476
|
|
|
477
|
|
|
478 <section name="Numeric conversion" id="numeric_conversion">
|
|
|
479
|
|
|
480 <para>
|
|
|
481 Several functions for numeric conversion are implemented in nginx:
|
|
|
482 </para>
|
|
|
483
|
|
|
484 <para>
|
|
|
485 <list type="bullet">
|
|
|
486
|
|
|
487 <listitem>
|
|
|
488 <literal>ngx_atoi(line, n)</literal> - converts a string of given length to a
|
|
|
489 positive integer of type <literal>ngx_int_t</literal>.
|
|
|
490 Returns <literal>NGX_ERROR</literal> on error
|
|
|
491 </listitem>
|
|
|
492
|
|
|
493 <listitem>
|
|
|
494 <literal>ngx_atosz(line, n)</literal> - same for <literal>ssize_t</literal>
|
|
|
495 type
|
|
|
496 </listitem>
|
|
|
497
|
|
|
498 <listitem>
|
|
|
499 <literal>ngx_atoof(line, n)</literal> - same for <literal>off_t</literal>
|
|
|
500 type
|
|
|
501 </listitem>
|
|
|
502
|
|
|
503 <listitem>
|
|
|
504 <literal>ngx_atotm(line, n)</literal> - same for <literal>time_t</literal>
|
|
|
505 type
|
|
|
506 </listitem>
|
|
|
507
|
|
|
508 <listitem>
|
|
|
509 <literal>ngx_atofp(line, n, point)</literal> - converts a fixed point floating
|
|
|
510 number of given length to a positive integer of type
|
|
|
511 <literal>ngx_int_t</literal>.
|
|
|
512 The result is shifted left by <literal>points</literal> decimal
|
|
|
513 positions. The string representation of the number is expected to have no more
|
|
|
514 than <literal>points</literal> fractional digits.
|
|
|
515 Returns <literal>NGX_ERROR</literal> on error. For example,
|
|
|
516 <literal>ngx_atofp("10.5", 4, 2)</literal> returns <literal>1050</literal>
|
|
|
517 </listitem>
|
|
|
518
|
|
|
519 <listitem>
|
|
|
520 <literal>ngx_hextoi(line, n)</literal> - converts hexadecimal representation of
|
|
|
521 a positive integer to <literal>ngx_int_t</literal>. Returns
|
|
|
522 <literal>NGX_ERROR</literal> on error
|
|
|
523 </listitem>
|
|
|
524
|
|
|
525 </list>
|
|
|
526 </para>
|
|
|
527
|
|
|
528 </section>
|
|
|
529
|
|
|
530
|
|
|
531 </section>
|
|
|
532
|
|
|
533
|
|
|
534 <section name="Containers" id="containers">
|
|
|
535
|
|
|
536
|
|
|
537 <section name="Array" id="array">
|
|
|
538
|
|
|
539 <para>
|
|
|
540 The nginx array type <literal>ngx_array_t</literal> is defined as follows
|
|
|
541 </para>
|
|
|
542
|
|
|
543
|
|
|
544 <programlisting>
|
|
|
545 typedef struct {
|
|
|
546 void *elts;
|
|
|
547 ngx_uint_t nelts;
|
|
|
548 size_t size;
|
|
|
549 ngx_uint_t nalloc;
|
|
|
550 ngx_pool_t *pool;
|
|
|
551 } ngx_array_t;
|
|
|
552 </programlisting>
|
|
|
553
|
|
|
554 <para>
|
|
|
555 The elements of array are available through the <literal>elts</literal> field.
|
|
|
556 The number of elements is held in the <literal>nelts</literal> field.
|
|
|
557 The <literal>size</literal> field holds the size of a single element and is set
|
|
|
558 when initializing the array.
|
|
|
559 </para>
|
|
|
560
|
|
|
561 <para>
|
|
|
562 An array can be created in a pool with the
|
|
|
563 <literal>ngx_array_create(pool, n, size)</literal> call.
|
|
|
564 An already allocated array object can be initialized with the
|
|
|
565 <literal>ngx_array_init(array, pool, n, size)</literal> call.
|
|
|
566 </para>
|
|
|
567
|
|
|
568
|
|
|
569 <programlisting>
|
|
|
570 ngx_array_t *a, b;
|
|
|
571
|
|
|
572 /* create an array of strings with preallocated memory for 10 elements */
|
|
|
573 a = ngx_array_create(pool, 10, sizeof(ngx_str_t));
|
|
|
574
|
|
|
575 /* initialize string array for 10 elements */
|
|
|
576 ngx_array_init(&b, pool, 10, sizeof(ngx_str_t));
|
|
|
577 </programlisting>
|
|
|
578
|
|
|
579 <para>
|
|
|
580 Adding elements to array are done with the following functions:
|
|
|
581 </para>
|
|
|
582
|
|
|
583 <para>
|
|
|
584 <list type="bullet">
|
|
|
585
|
|
|
586 <listitem>
|
|
|
587 <literal>ngx_array_push(a)</literal> adds one tail element and returns pointer
|
|
|
588 to it
|
|
|
589 </listitem>
|
|
|
590
|
|
|
591 <listitem>
|
|
|
592 <literal>ngx_array_push_n(a, n)</literal> adds <literal>n</literal> tail elements
|
|
|
593 and returns pointer to the first one
|
|
|
594 </listitem>
|
|
|
595
|
|
|
596 </list>
|
|
|
597 </para>
|
|
|
598
|
|
|
599 <para>
|
|
|
600 If currently allocated memory is not enough for new elements, a new memory for
|
|
|
601 elements is allocated and existing elements are copied to that memory.
|
|
|
602 The new memory block is normally twice as large, as the existing one.
|
|
|
603 </para>
|
|
|
604
|
|
|
605
|
|
|
606 <programlisting>
|
|
|
607 s = ngx_array_push(a);
|
|
|
608 ss = ngx_array_push_n(&b, 3);
|
|
|
609 </programlisting>
|
|
|
610
|
|
|
611 </section>
|
|
|
612
|
|
|
613
|
|
|
614 <section name="List" id="list">
|
|
|
615
|
|
|
616 <para>
|
|
|
617 List in nginx is a sequence of arrays, optimized for inserting a potentially
|
|
|
618 large number of items. The list type is defined as follows:
|
|
|
619 </para>
|
|
|
620
|
|
|
621
|
|
|
622 <programlisting>
|
|
|
623 typedef struct {
|
|
|
624 ngx_list_part_t *last;
|
|
|
625 ngx_list_part_t part;
|
|
|
626 size_t size;
|
|
|
627 ngx_uint_t nalloc;
|
|
|
628 ngx_pool_t *pool;
|
|
|
629 } ngx_list_t;
|
|
|
630 </programlisting>
|
|
|
631
|
|
|
632 <para>
|
|
|
633 The actual items are store in list parts, defined as follows:
|
|
|
634 </para>
|
|
|
635
|
|
|
636
|
|
|
637 <programlisting>
|
|
|
638 typedef struct ngx_list_part_s ngx_list_part_t;
|
|
|
639
|
|
|
640 struct ngx_list_part_s {
|
|
|
641 void *elts;
|
|
|
642 ngx_uint_t nelts;
|
|
|
643 ngx_list_part_t *next;
|
|
|
644 };
|
|
|
645 </programlisting>
|
|
|
646
|
|
|
647 <para>
|
|
|
648 Initially, a list must be initialized by calling
|
|
|
649 <literal>ngx_list_init(list, pool, n, size)</literal> or created by calling
|
|
|
650 <literal>ngx_list_create(pool, n, size)</literal>.
|
|
|
651 Both functions receive the size of a single item and a number of items per list
|
|
|
652 part.
|
|
|
653 The <literal>ngx_list_push(list)</literal> function is used to add an item to the
|
|
|
654 list. Iterating over the items is done by direct accessing the list fields, as
|
|
|
655 seen in the example:
|
|
|
656 </para>
|
|
|
657
|
|
|
658
|
|
|
659 <programlisting>
|
|
|
660 ngx_str_t *v;
|
|
|
661 ngx_uint_t i;
|
|
|
662 ngx_list_t *list;
|
|
|
663 ngx_list_part_t *part;
|
|
|
664
|
|
|
665 list = ngx_list_create(pool, 100, sizeof(ngx_str_t));
|
|
|
666 if (list == NULL) { /* error */ }
|
|
|
667
|
|
|
668 /* add items to the list */
|
|
|
669
|
|
|
670 v = ngx_list_push(list);
|
|
|
671 if (v == NULL) { /* error */ }
|
|
|
672 ngx_str_set(v, “foo”);
|
|
|
673
|
|
|
674 v = ngx_list_push(list);
|
|
|
675 if (v == NULL) { /* error */ }
|
|
|
676 ngx_str_set(v, “bar”);
|
|
|
677
|
|
|
678 /* iterate over the list */
|
|
|
679
|
|
|
680 part = &list->part;
|
|
|
681 v = part->elts;
|
|
|
682
|
|
|
683 for (i = 0; /* void */; i++) {
|
|
|
684
|
|
|
685 if (i >= part->nelts) {
|
|
|
686 if (part->next == NULL) {
|
|
|
687 break;
|
|
|
688 }
|
|
|
689
|
|
|
690 part = part->next;
|
|
|
691 v = part->elts;
|
|
|
692 i = 0;
|
|
|
693 }
|
|
|
694
|
|
|
695 ngx_do_smth(&v[i]);
|
|
|
696 }
|
|
|
697 </programlisting>
|
|
|
698
|
|
|
699 <para>
|
|
|
700 The primary use for the list in nginx is HTTP input and output headers.
|
|
|
701 </para>
|
|
|
702
|
|
|
703 <para>
|
|
|
704 The list does not support item removal.
|
|
|
705 However, when needed, items can internally be marked as missing without actual
|
|
|
706 removing from the list.
|
|
|
707 For example, HTTP output headers which are stored as
|
|
|
708 <literal>ngx_table_elt_t</literal> objects, are marked as missing by setting
|
|
|
709 the <literal>hash</literal> field of <literal>ngx_table_elt_t</literal> to
|
|
|
710 zero. Such items are explicitly skipped, when iterating over the headers.
|
|
|
711 </para>
|
|
|
712
|
|
|
713 </section>
|
|
|
714
|
|
|
715
|
|
|
716 <section name="Queue" id="queue">
|
|
|
717
|
|
|
718 <para>
|
|
|
719 Queue in nginx is an intrusive doubly linked list, with each node defined as
|
|
|
720 follows:
|
|
|
721 </para>
|
|
|
722
|
|
|
723
|
|
|
724 <programlisting>
|
|
|
725 typedef struct ngx_queue_s ngx_queue_t;
|
|
|
726
|
|
|
727 struct ngx_queue_s {
|
|
|
728 ngx_queue_t *prev;
|
|
|
729 ngx_queue_t *next;
|
|
|
730 };
|
|
|
731 </programlisting>
|
|
|
732
|
|
|
733 <para>
|
|
|
734 The head queue node is not linked with any data. Before using, the list head
|
|
|
735 should be initialized with <literal>ngx_queue_init(q)</literal> call.
|
|
|
736 Queues support the following operations:
|
|
|
737 </para>
|
|
|
738
|
|
|
739 <para>
|
|
|
740 <list type="bullet">
|
|
|
741
|
|
|
742 <listitem>
|
|
|
743 <literal>ngx_queue_insert_head(h, x)</literal>,
|
|
|
744 <literal>ngx_queue_insert_tail(h, x)</literal> - insert a new node
|
|
|
745 </listitem>
|
|
|
746
|
|
|
747 <listitem>
|
|
|
748 <literal>ngx_queue_remove(x)</literal> - remove a queue node
|
|
|
749 </listitem>
|
|
|
750
|
|
|
751 <listitem>
|
|
|
752 <literal>ngx_queue_split(h, q, n)</literal> - split a queue at a node,
|
|
|
753 queue tail is returned in a separate queue
|
|
|
754 </listitem>
|
|
|
755
|
|
|
756 <listitem>
|
|
|
757 <literal>ngx_queue_add(h, n)</literal> - add second queue to the first queue
|
|
|
758 </listitem>
|
|
|
759
|
|
|
760 <listitem>
|
|
|
761 <literal>ngx_queue_head(h)</literal>,
|
|
|
762 <literal>ngx_queue_last(h)</literal> - get first or last queue node
|
|
|
763 </listitem>
|
|
|
764
|
|
|
765 <listitem>
|
|
|
766 <literal>ngx_queue_sentinel(h)</literal>
|
|
|
767 - get a queue sentinel object to end iteration at
|
|
|
768 </listitem>
|
|
|
769
|
|
|
770 <listitem>
|
|
|
771 <literal>ngx_queue_data(q, type, link)</literal> - get reference to the beginning of a
|
|
|
772 queue node data structure, considering the queue field offset in it
|
|
|
773 </listitem>
|
|
|
774
|
|
|
775 </list>
|
|
|
776 </para>
|
|
|
777
|
|
|
778 <para>
|
|
|
779 Example:
|
|
|
780 </para>
|
|
|
781
|
|
|
782
|
|
|
783 <programlisting>
|
|
|
784 typedef struct {
|
|
|
785 ngx_str_t value;
|
|
|
786 ngx_queue_t queue;
|
|
|
787 } ngx_foo_t;
|
|
|
788
|
|
|
789 ngx_foo_t *f;
|
|
|
790 ngx_queue_t values;
|
|
|
791
|
|
|
792 ngx_queue_init(&values);
|
|
|
793
|
|
|
794 f = ngx_palloc(pool, sizeof(ngx_foo_t));
|
|
|
795 if (f == NULL) { /* error */ }
|
|
|
796 ngx_str_set(&f->value, “foo”);
|
|
|
797
|
|
|
798 ngx_queue_insert_tail(&values, f);
|
|
|
799
|
|
|
800 /* insert more nodes here */
|
|
|
801
|
|
|
802 for (q = ngx_queue_head(&values);
|
|
|
803 q != ngx_queue_sentinel(&values);
|
|
|
804 q = ngx_queue_next(q))
|
|
|
805 {
|
|
|
806 f = ngx_queue_data(q, ngx_foo_t, queue);
|
|
|
807
|
|
|
808 ngx_do_smth(&f->value);
|
|
|
809 }
|
|
|
810 </programlisting>
|
|
|
811
|
|
|
812 </section>
|
|
|
813
|
|
|
814
|
|
|
815 <section name="Red-Black tree" id="red_black_tree">
|
|
|
816
|
|
|
817 <para>
|
|
|
818 The <literal>src/core/ngx_rbtree.h</literal> header file provides access to the
|
|
|
819 effective implementation of red-black trees.
|
|
|
820 </para>
|
|
|
821
|
|
|
822
|
|
|
823 <programlisting>
|
|
|
824 typedef struct {
|
|
|
825 ngx_rbtree_t rbtree;
|
|
|
826 ngx_rbtree_node_t sentinel;
|
|
|
827
|
|
|
828 /* custom per-tree data here */
|
|
|
829 } my_tree_t;
|
|
|
830
|
|
|
831 typedef struct {
|
|
|
832 ngx_rbtree_node_t rbnode;
|
|
|
833
|
|
|
834 /* custom per-node data */
|
|
|
835 foo_t val;
|
|
|
836 } my_node_t;
|
|
|
837 </programlisting>
|
|
|
838
|
|
|
839 <para>
|
|
|
840 To deal with a tree as a whole, you need two nodes: root and sentinel.
|
|
|
841 Typically, they are added to some custom structure, thus allowing to
|
|
|
842 organize your data into a tree which leaves contain a link to or embed
|
|
|
843 your data.
|
|
|
844 </para>
|
|
|
845
|
|
|
846 <para>
|
|
|
847 To initialize a tree:
|
|
|
848 </para>
|
|
|
849
|
|
|
850
|
|
|
851 <programlisting>
|
|
|
852 my_tree_t root;
|
|
|
853
|
|
|
854 ngx_rbtree_init(&root.rbtree, &root.sentinel, insert_value_function);
|
|
|
855 </programlisting>
|
|
|
856
|
|
|
857 <para>
|
|
|
858 The <literal>insert_value_function</literal> is a function that is
|
|
|
859 responsible for traversing the tree and inserting new values into correct
|
|
|
860 place.
|
|
|
861 For example, the <literal>ngx_str_rbtree_insert_value</literal> functions is
|
|
|
862 designed to deal with <literal>ngx_str_t</literal> type.
|
|
|
863 </para>
|
|
|
864
|
|
|
865
|
|
|
866 <programlisting>
|
|
|
867 void ngx_str_rbtree_insert_value(ngx_rbtree_node_t *temp,
|
|
|
868 ngx_rbtree_node_t *node,
|
|
|
869 ngx_rbtree_node_t *sentinel)
|
|
|
870 </programlisting>
|
|
|
871
|
|
|
872 <para>
|
|
|
873 Its arguments are pointers to a root node of an insertion, newly created node
|
|
|
874 to be added, and a tree sentinel.
|
|
|
875 </para>
|
|
|
876
|
|
|
877 <para>
|
|
|
878 The traversal is pretty straightforward and can be demonstrated with the
|
|
|
879 following lookup function pattern:
|
|
|
880 </para>
|
|
|
881
|
|
|
882
|
|
|
883 <programlisting>
|
|
|
884 my_node_t *
|
|
|
885 my_rbtree_lookup(ngx_rbtree_t *rbtree, foo_t *val, uint32_t hash)
|
|
|
886 {
|
|
|
887 ngx_int_t rc;
|
|
|
888 my_node_t *n;
|
|
|
889 ngx_rbtree_node_t *node, *sentinel;
|
|
|
890
|
|
|
891 node = rbtree->root;
|
|
|
892 sentinel = rbtree->sentinel;
|
|
|
893
|
|
|
894 while (node != sentinel) {
|
|
|
895
|
|
|
896 n = (my_node_t *) node;
|
|
|
897
|
|
|
898 if (hash != node->key) {
|
|
|
899 node = (hash < node->key) ? node->left : node->right;
|
|
|
900 continue;
|
|
|
901 }
|
|
|
902
|
|
|
903 rc = compare(val, node->val);
|
|
|
904
|
|
|
905 if (rc < 0) {
|
|
|
906 node = node->left;
|
|
|
907 continue;
|
|
|
908 }
|
|
|
909
|
|
|
910 if (rc > 0) {
|
|
|
911 node = node->right;
|
|
|
912 continue;
|
|
|
913 }
|
|
|
914
|
|
|
915 return n;
|
|
|
916 }
|
|
|
917
|
|
|
918 return NULL;
|
|
|
919 }
|
|
|
920 </programlisting>
|
|
|
921
|
|
|
922 <para>
|
|
|
923 The <literal>compare()</literal> is a classic comparator function returning
|
|
|
924 value less, equal or greater than zero. To speed up lookups and avoid comparing
|
|
|
925 user objects that can be big, integer hash field is used.
|
|
|
926 </para>
|
|
|
927
|
|
|
928 <para>
|
|
|
929 To add a node to a tree, allocate a new node, initialize it and call
|
|
|
930 <literal>ngx_rbtree_insert()</literal>:
|
|
|
931 </para>
|
|
|
932
|
|
|
933
|
|
|
934 <programlisting>
|
|
|
935 my_node_t *my_node;
|
|
|
936 ngx_rbtree_node_t *node;
|
|
|
937
|
|
|
938 my_node = ngx_palloc(...);
|
|
|
939 init_custom_data(&my_node->val);
|
|
|
940
|
|
|
941 node = &my_node->rbnode;
|
|
|
942 node->key = create_key(my_node->val);
|
|
|
943
|
|
|
944 ngx_rbtree_insert(&root->rbtree, node);
|
|
|
945 </programlisting>
|
|
|
946
|
|
|
947 <para>
|
|
|
948 to remove a node:
|
|
|
949 </para>
|
|
|
950
|
|
|
951
|
|
|
952 <programlisting>
|
|
|
953 ngx_rbtree_delete(&root->rbtree, node);
|
|
|
954 </programlisting>
|
|
|
955
|
|
|
956 </section>
|
|
|
957
|
|
|
958
|
|
|
959 </section>
|
|
|
960
|
|
|
961
|
|
|
962 <section name="Memory management" id="memory_management">
|
|
|
963
|
|
|
964
|
|
|
965 <section name="Heap" id="heap">
|
|
|
966
|
|
|
967 <para>
|
|
|
968 To allocate memory from system heap, the following functions are provided by
|
|
|
969 nginx:
|
|
|
970 </para>
|
|
|
971
|
|
|
972 <para>
|
|
|
973 <list type="bullet">
|
|
|
974
|
|
|
975 <listitem>
|
|
|
976 <literal>ngx_alloc(size, log)</literal> - allocate memory from system heap.
|
|
|
977 This is a wrapper around <literal>malloc()</literal> with logging support.
|
|
|
978 Allocation error and debugging information is logged to <literal>log</literal>
|
|
|
979 </listitem>
|
|
|
980
|
|
|
981 <listitem>
|
|
|
982 <literal>ngx_calloc(size, log)</literal> - same as
|
|
|
983 <literal>ngx_alloc()</literal>, but memory is filled with zeroes after
|
|
|
984 allocation
|
|
|
985 </listitem>
|
|
|
986
|
|
|
987 <listitem>
|
|
|
988 <literal>ngx_memalign(alignment, size, log)</literal> - allocate aligned memory
|
|
|
989 from system heap. This is a wrapper around <literal>posix_memalign()</literal>
|
|
|
990 on those platforms which provide it.
|
|
|
991 Otherwise implementation falls back to <literal>ngx_alloc()</literal> which
|
|
|
992 provides maximum alignment
|
|
|
993 </listitem>
|
|
|
994
|
|
|
995 <listitem>
|
|
|
996 <literal>ngx_free(p)</literal> - free allocated memory.
|
|
|
997 This is a wrapper around <literal>free()</literal>
|
|
|
998 </listitem>
|
|
|
999
|
|
|
1000 </list>
|
|
|
1001 </para>
|
|
|
1002
|
|
|
1003 </section>
|
|
|
1004
|
|
|
1005
|
|
|
1006 <section name="Pool" id="pool">
|
|
|
1007
|
|
|
1008 <para>
|
|
|
1009 Most nginx allocations are done in pools. Memory allocated in an nginx pool is
|
|
|
1010 freed automatically when the pool in destroyed. This provides good
|
|
|
1011 allocation performance and makes memory control easy.
|
|
|
1012 </para>
|
|
|
1013
|
|
|
1014 <para>
|
|
|
1015 A pool internally allocates objects in continuous blocks of memory. Once a
|
|
|
1016 block is full, a new one is allocated and added to the pool memory
|
|
|
1017 block list. When a large allocation is requested which does not fit into
|
|
|
1018 a block, such allocation is forwarded to the system allocator and the
|
|
|
1019 returned pointer is stored in the pool for further deallocation.
|
|
|
1020 </para>
|
|
|
1021
|
|
|
1022 <para>
|
|
|
1023 Nginx pool has the type <literal>ngx_pool_t</literal>.
|
|
|
1024 The following operations are supported:
|
|
|
1025 </para>
|
|
|
1026
|
|
|
1027 <para>
|
|
|
1028 <list type="bullet">
|
|
|
1029
|
|
|
1030 <listitem>
|
|
|
1031 <literal>ngx_create_pool(size, log)</literal> - create a pool with given
|
|
|
1032 block size. The pool object returned is allocated in the pool as well.
|
|
|
1033 </listitem>
|
|
|
1034
|
|
|
1035 <listitem>
|
|
|
1036 <literal>ngx_destroy_pool(pool)</literal> - free all pool memory, including
|
|
|
1037 the pool object itself.
|
|
|
1038 </listitem>
|
|
|
1039
|
|
|
1040 <listitem>
|
|
|
1041 <literal>ngx_palloc(pool, size)</literal> - allocate aligned memory from pool
|
|
|
1042 </listitem>
|
|
|
1043
|
|
|
1044 <listitem>
|
|
|
1045 <literal>ngx_pcalloc(pool, size)</literal> - allocated aligned memory
|
|
|
1046 from pool and fill it with zeroes
|
|
|
1047 </listitem>
|
|
|
1048
|
|
|
1049 <listitem>
|
|
|
1050 <literal>ngx_pnalloc(pool, size)</literal> - allocate unaligned memory from pool.
|
|
|
1051 Mostly used for allocating strings
|
|
|
1052 </listitem>
|
|
|
1053
|
|
|
1054 <listitem>
|
|
|
1055 <literal>ngx_pfree(pool, p)</literal> - free memory, previously allocated
|
|
|
1056 in the pool.
|
|
|
1057 Only allocations, forwarded to the system allocator, can be freed.
|
|
|
1058 </listitem>
|
|
|
1059
|
|
|
1060 </list>
|
|
|
1061 </para>
|
|
|
1062
|
|
|
1063 <programlisting>
|
|
|
1064 u_char *p;
|
|
|
1065 ngx_str_t *s;
|
|
|
1066 ngx_pool_t *pool;
|
|
|
1067
|
|
|
1068 pool = ngx_create_pool(1024, log);
|
|
|
1069 if (pool == NULL) { /* error */ }
|
|
|
1070
|
|
|
1071 s = ngx_palloc(pool, sizeof(ngx_str_t));
|
|
|
1072 if (s == NULL) { /* error */ }
|
|
|
1073 ngx_str_set(s, “foo”);
|
|
|
1074
|
|
|
1075 p = ngx_pnalloc(pool, 3);
|
|
|
1076 if (p == NULL) { /* error */ }
|
|
|
1077 ngx_memcpy(p, “foo”, 3);
|
|
|
1078 </programlisting>
|
|
|
1079
|
|
|
1080 <para>
|
|
|
1081 Since chain links <literal>ngx_chain_t</literal> are actively used in nginx,
|
|
|
1082 nginx pool provides a way to reuse them.
|
|
|
1083 The <literal>chain</literal> field of <literal>ngx_pool_t</literal> keeps a
|
|
|
1084 list of previously allocated links ready for reuse. For efficient allocation of
|
|
|
1085 a chain link in a pool, the function
|
|
|
1086 <literal>ngx_alloc_chain_link(pool)</literal> should be used.
|
|
|
1087 This function looks up a free chain link in the pool list and only if it's
|
|
|
1088 empty allocates a new one. To free a link <literal>ngx_free_chain(pool, cl)</literal>
|
|
|
1089 should be called.
|
|
|
1090 </para>
|
|
|
1091
|
|
|
1092 <para>
|
|
|
1093 Cleanup handlers can be registered in a pool.
|
|
|
1094 Cleanup handler is a callback with an argument which is called when pool is
|
|
|
1095 destroyed.
|
|
|
1096 Pool is usually tied with a specific nginx object (like HTTP request) and
|
|
|
1097 destroyed in the end of that object’s lifetime, releasing the object itself.
|
|
1902
|
1098 Registering a pool cleanup is a convenient way to release resources, close file
|
|
1899
|
1099 descriptors or make final adjustments to shared data, associated with the main
|
|
|
1100 object.
|
|
|
1101 </para>
|
|
|
1102
|
|
|
1103 <para>
|
|
|
1104 A pool cleanup is registered by calling <literal>ngx_pool_cleanup_add(pool,
|
|
|
1105 size)</literal> which returns <literal>ngx_pool_cleanup_t</literal> pointer to
|
|
|
1106 be filled by the caller. The <literal>size</literal> argument allows allocating
|
|
|
1107 context for the cleanup handler.
|
|
|
1108 </para>
|
|
|
1109
|
|
|
1110
|
|
|
1111 <programlisting>
|
|
|
1112 ngx_pool_cleanup_t *cln;
|
|
|
1113
|
|
|
1114 cln = ngx_pool_cleanup_add(pool, 0);
|
|
|
1115 if (cln == NULL) { /* error */ }
|
|
|
1116
|
|
|
1117 cln->handler = ngx_my_cleanup;
|
|
|
1118 cln->data = “foo”;
|
|
|
1119
|
|
|
1120 ...
|
|
|
1121
|
|
|
1122 static void
|
|
|
1123 ngx_my_cleanup(void *data)
|
|
|
1124 {
|
|
|
1125 u_char *msg = data;
|
|
|
1126
|
|
|
1127 ngx_do_smth(msg);
|
|
|
1128 }
|
|
|
1129 </programlisting>
|
|
|
1130
|
|
|
1131 </section>
|
|
|
1132
|
|
|
1133
|
|
|
1134 <section name="Shared memory" id="shared_memory">
|
|
|
1135
|
|
|
1136 <para>
|
|
|
1137 Shared memory is used by nginx to share common data between processes.
|
|
|
1138 Function <literal>ngx_shared_memory_add(cf, name, size, tag)</literal> adds a
|
|
|
1139 new shared memory entry <literal>ngx_shm_zone_t</literal> to the cycle. The
|
|
|
1140 function receives <literal>name</literal> and <literal>size</literal> of the
|
|
|
1141 zone.
|
|
|
1142 Each shared zone must have a unique name.
|
|
|
1143 If a shared zone entry with the provided name exists, the old zone entry is
|
|
|
1144 reused, if its tag value matches too.
|
|
|
1145 Mismatched tag is considered an error.
|
|
|
1146 Usually, the address of the module structure is passed as tag, making it
|
|
|
1147 possible to reuse shared zones by name within one nginx module.
|
|
|
1148 </para>
|
|
|
1149
|
|
|
1150 <para>
|
|
|
1151 The shared memory entry structure <literal>ngx_shm_zone_t</literal> has the
|
|
|
1152 following fields:
|
|
|
1153 </para>
|
|
|
1154
|
|
|
1155 <para>
|
|
|
1156 <list type="bullet">
|
|
|
1157
|
|
|
1158 <listitem>
|
|
|
1159 <literal>init</literal> - initialization callback, called after shared zone is
|
|
|
1160 mapped to actual memory
|
|
|
1161 </listitem>
|
|
|
1162
|
|
|
1163 <listitem>
|
|
|
1164 <literal>data</literal> - data context, used to pass arbitrary data to the
|
|
|
1165 <literal>init</literal> callback
|
|
|
1166 </listitem>
|
|
|
1167
|
|
|
1168 <listitem>
|
|
|
1169 <literal>noreuse</literal> - flag, disabling shared zone reuse from the
|
|
|
1170 old cycle
|
|
|
1171 </listitem>
|
|
|
1172
|
|
|
1173 <listitem>
|
|
|
1174 <literal>tag</literal> - shared zone tag
|
|
|
1175 </listitem>
|
|
|
1176
|
|
|
1177 <listitem>
|
|
|
1178 <literal>shm</literal> - platform-specific object of type
|
|
|
1179 <literal>ngx_shm_t</literal>, having at least the following fields:
|
|
|
1180 <list type="bullet">
|
|
|
1181
|
|
|
1182 <listitem>
|
|
|
1183 <literal>addr</literal> - mapped shared memory address, initially NULL
|
|
|
1184 </listitem>
|
|
|
1185
|
|
|
1186 <listitem>
|
|
|
1187 <literal>size</literal> - shared memory size
|
|
|
1188 </listitem>
|
|
|
1189
|
|
|
1190 <listitem>
|
|
|
1191 <literal>name</literal> - shared memory name
|
|
|
1192 </listitem>
|
|
|
1193
|
|
|
1194 <listitem>
|
|
|
1195 <literal>log</literal> - shared memory log
|
|
|
1196 </listitem>
|
|
|
1197
|
|
|
1198 <listitem>
|
|
|
1199 <literal>exists</literal> - flag, showing that shared memory was inherited
|
|
|
1200 from the master process (Windows-specific)
|
|
|
1201 </listitem>
|
|
|
1202
|
|
|
1203 </list>
|
|
|
1204 </listitem>
|
|
|
1205
|
|
|
1206 </list>
|
|
|
1207 </para>
|
|
|
1208
|
|
|
1209 <para>
|
|
|
1210 Shared zone entries are mapped to actual memory in
|
|
|
1211 <literal>ngx_init_cycle()</literal> after configuration is parsed.
|
|
|
1212 On POSIX systems, <literal>mmap()</literal> syscall is used to create shared
|
|
|
1213 anonymous mapping.
|
|
|
1214 On Windows, <literal>CreateFileMapping()/MapViewOfFileEx()</literal> pair is
|
|
|
1215 used.
|
|
|
1216 </para>
|
|
|
1217
|
|
|
1218 <para>
|
|
|
1219 For allocating in shared memory, nginx provides slab pool
|
|
|
1220 <literal>ngx_slab_pool_t</literal>.
|
|
|
1221 In each nginx shared zone, a slab pool is automatically created for allocating
|
|
|
1222 memory in that zone.
|
|
|
1223 The pool is located in the beginning of the shared zone and can be accessed by
|
|
|
1224 the expression <literal>(ngx_slab_pool_t *) shm_zone->shm.addr</literal>.
|
|
|
1225 Allocation in shared zone is done by calling one of the functions
|
|
|
1226 <literal>ngx_slab_alloc(pool, size)/ngx_slab_calloc(pool, size)</literal>.
|
|
|
1227 Memory is freed by calling <literal>ngx_slab_free(pool, p)</literal>.
|
|
|
1228 </para>
|
|
|
1229
|
|
|
1230 <para>
|
|
|
1231 Slab pool divides all shared zone into pages.
|
|
|
1232 Each page is used for allocating objects of the same size.
|
|
|
1233 Only the sizes which are powers of 2, and not less than 8, are considered.
|
|
|
1234 Other sizes are rounded up to one of these values.
|
|
|
1235 For each page, a bitmask is kept, showing which blocks within that page are in
|
|
|
1236 use and which are free for allocation.
|
|
|
1237 For sizes greater than half-page (usually, 2048 bytes), allocation is done by
|
|
|
1238 entire pages.
|
|
|
1239 </para>
|
|
|
1240
|
|
|
1241 <para>
|
|
|
1242 To protect data in shared memory from concurrent access, mutex is available in
|
|
|
1243 the <literal>mutex</literal> field of <literal>ngx_slab_pool_t</literal>.
|
|
|
1244 The mutex is used by the slab pool while allocating and freeing memory.
|
|
|
1245 However, it can be used to protect any other user data structures,
|
|
|
1246 allocated in the shared zone.
|
|
|
1247 Locking is done by calling
|
|
|
1248 <literal>ngx_shmtx_lock(&shpool->mutex)</literal>, unlocking is done by
|
|
|
1249 calling <literal>ngx_shmtx_unlock(&shpool->mutex)</literal>.
|
|
|
1250 </para>
|
|
|
1251
|
|
|
1252
|
|
|
1253 <programlisting>
|
|
|
1254 ngx_str_t name;
|
|
|
1255 ngx_foo_ctx_t *ctx;
|
|
|
1256 ngx_shm_zone_t *shm_zone;
|
|
|
1257
|
|
|
1258 ngx_str_set(&name, "foo");
|
|
|
1259
|
|
|
1260 /* allocate shared zone context */
|
|
|
1261 ctx = ngx_pcalloc(cf->pool, sizeof(ngx_foo_ctx_t));
|
|
|
1262 if (ctx == NULL) {
|
|
|
1263 /* error */
|
|
|
1264 }
|
|
|
1265
|
|
|
1266 /* add an entry for 65k shared zone */
|
|
|
1267 shm_zone = ngx_shared_memory_add(cf, &name, 65536, &ngx_foo_module);
|
|
|
1268 if (shm_zone == NULL) {
|
|
|
1269 /* error */
|
|
|
1270 }
|
|
|
1271
|
|
|
1272 /* register init callback and context */
|
|
|
1273 shm_zone->init = ngx_foo_init_zone;
|
|
|
1274 shm_zone->data = ctx;
|
|
|
1275
|
|
|
1276
|
|
|
1277 ...
|
|
|
1278
|
|
|
1279
|
|
|
1280 static ngx_int_t
|
|
|
1281 ngx_foo_init_zone(ngx_shm_zone_t *shm_zone, void *data)
|
|
|
1282 {
|
|
|
1283 ngx_foo_ctx_t *octx = data;
|
|
|
1284
|
|
|
1285 size_t len;
|
|
|
1286 ngx_foo_ctx_t *ctx;
|
|
|
1287 ngx_slab_pool_t *shpool;
|
|
|
1288
|
|
|
1289 value = shm_zone->data;
|
|
|
1290
|
|
|
1291 if (octx) {
|
|
|
1292 /* reusing a shared zone from old cycle */
|
|
|
1293 ctx->value = octx->value;
|
|
|
1294 return NGX_OK;
|
|
|
1295 }
|
|
|
1296
|
|
|
1297 shpool = (ngx_slab_pool_t *) shm_zone->shm.addr;
|
|
|
1298
|
|
|
1299 if (shm_zone->shm.exists) {
|
|
|
1300 /* initialize shared zone context in Windows nginx worker */
|
|
|
1301 ctx->value = shpool->data;
|
|
|
1302 return NGX_OK;
|
|
|
1303 }
|
|
|
1304
|
|
|
1305 /* initialize shared zone */
|
|
|
1306
|
|
|
1307 ctx->value = ngx_slab_alloc(shpool, sizeof(ngx_uint_t));
|
|
|
1308 if (ctx->value == NULL) {
|
|
|
1309 return NGX_ERROR;
|
|
|
1310 }
|
|
|
1311
|
|
|
1312 shpool->data = ctx->value;
|
|
|
1313
|
|
|
1314 return NGX_OK;
|
|
|
1315 }
|
|
|
1316 </programlisting>
|
|
|
1317
|
|
|
1318 </section>
|
|
|
1319
|
|
|
1320
|
|
|
1321 </section>
|
|
|
1322
|
|
|
1323
|
|
|
1324 <section name="Logging" id="logging">
|
|
|
1325
|
|
|
1326 <para>
|
|
|
1327 For logging nginx code uses <literal>ngx_log_t</literal> objects.
|
|
|
1328 Nginx logger provides support for several types of output:
|
|
|
1329
|
|
|
1330 <list type="bullet">
|
|
|
1331
|
|
|
1332 <listitem>
|
|
|
1333 stderr - logging to standard error output
|
|
|
1334 </listitem>
|
|
|
1335
|
|
|
1336 <listitem>
|
|
|
1337 file - logging to file
|
|
|
1338 </listitem>
|
|
|
1339
|
|
|
1340 <listitem>
|
|
|
1341 syslog - logging to syslog
|
|
|
1342 </listitem>
|
|
|
1343
|
|
|
1344 <listitem>
|
|
|
1345 memory - logging to internal memory storage for development purposes.
|
|
|
1346 The memory could be accessed later with debugger
|
|
|
1347 </listitem>
|
|
|
1348
|
|
|
1349 </list>
|
|
|
1350 </para>
|
|
|
1351
|
|
|
1352 <para>
|
|
|
1353 A logger instance may actually be a chain of loggers, linked to each other with
|
|
|
1354 the <literal>next</literal> field.
|
|
|
1355 Each message is written to all loggers in chain.
|
|
|
1356 </para>
|
|
|
1357
|
|
|
1358 <para>
|
|
|
1359 Each logger has an error level which limits the messages written to that log.
|
|
|
1360 The following error levels are supported by nginx:
|
|
|
1361 </para>
|
|
|
1362
|
|
|
1363 <para>
|
|
|
1364 <list type="bullet">
|
|
|
1365
|
|
|
1366 <listitem>
|
|
|
1367 <literal>NGX_LOG_EMERG</literal>
|
|
|
1368 </listitem>
|
|
|
1369
|
|
|
1370 <listitem>
|
|
|
1371 <literal>NGX_LOG_ALERT</literal>
|
|
|
1372 </listitem>
|
|
|
1373
|
|
|
1374 <listitem>
|
|
|
1375 <literal>NGX_LOG_CRIT</literal>
|
|
|
1376 </listitem>
|
|
|
1377
|
|
|
1378 <listitem>
|
|
|
1379 <literal>NGX_LOG_ERR</literal>
|
|
|
1380 </listitem>
|
|
|
1381
|
|
|
1382 <listitem>
|
|
|
1383 <literal>NGX_LOG_WARN</literal>
|
|
|
1384 </listitem>
|
|
|
1385
|
|
|
1386 <listitem>
|
|
|
1387 <literal>NGX_LOG_NOTICE</literal>
|
|
|
1388 </listitem>
|
|
|
1389
|
|
|
1390 <listitem>
|
|
|
1391 <literal>NGX_LOG_INFO</literal>
|
|
|
1392 </listitem>
|
|
|
1393
|
|
|
1394 <listitem>
|
|
|
1395 <literal>NGX_LOG_DEBUG</literal>
|
|
|
1396 </listitem>
|
|
|
1397
|
|
|
1398 </list>
|
|
|
1399 </para>
|
|
|
1400
|
|
|
1401 <para>
|
|
|
1402 For debug logging, debug mask is checked as well. The following debug masks
|
|
|
1403 exist:
|
|
|
1404 </para>
|
|
|
1405
|
|
|
1406 <para>
|
|
|
1407 <list type="bullet">
|
|
|
1408
|
|
|
1409 <listitem>
|
|
|
1410 <literal>NGX_LOG_DEBUG_CORE</literal>
|
|
|
1411 </listitem>
|
|
|
1412
|
|
|
1413 <listitem>
|
|
|
1414 <literal>NGX_LOG_DEBUG_ALLOC</literal>
|
|
|
1415 </listitem>
|
|
|
1416
|
|
|
1417 <listitem>
|
|
|
1418 <literal>NGX_LOG_DEBUG_MUTEX</literal>
|
|
|
1419 </listitem>
|
|
|
1420
|
|
|
1421 <listitem>
|
|
|
1422 <literal>NGX_LOG_DEBUG_EVENT</literal>
|
|
|
1423 </listitem>
|
|
|
1424
|
|
|
1425 <listitem>
|
|
|
1426 <literal>NGX_LOG_DEBUG_HTTP</literal>
|
|
|
1427 </listitem>
|
|
|
1428
|
|
|
1429 <listitem>
|
|
|
1430 <literal>NGX_LOG_DEBUG_MAIL</literal>
|
|
|
1431 </listitem>
|
|
|
1432
|
|
|
1433 <listitem>
|
|
|
1434 <literal>NGX_LOG_DEBUG_STREAM</literal>
|
|
|
1435 </listitem>
|
|
|
1436
|
|
|
1437 </list>
|
|
|
1438 </para>
|
|
|
1439
|
|
|
1440 <para>
|
|
|
1441 Normally, loggers are created by existing nginx code from
|
|
|
1442 <literal>error_log</literal> directives and are available at nearly every stage
|
|
|
1443 of processing in cycle, configuration, client connection and other objects.
|
|
|
1444 </para>
|
|
|
1445
|
|
|
1446 <para>
|
|
|
1447 Nginx provides the following logging macros:
|
|
|
1448 </para>
|
|
|
1449
|
|
|
1450 <para>
|
|
|
1451 <list type="bullet">
|
|
|
1452
|
|
|
1453 <listitem>
|
|
|
1454 <literal>ngx_log_error(level, log, err, fmt, ...)</literal> - error logging
|
|
|
1455 </listitem>
|
|
|
1456
|
|
|
1457 <listitem>
|
|
|
1458 <literal>ngx_log_debug0(level, log, err, fmt)</literal>,
|
|
|
1459 <literal>ngx_log_debug1(level, log, err, fmt, arg1)</literal> etc - debug
|
|
|
1460 logging, up to 8 formatting arguments are supported
|
|
|
1461 </listitem>
|
|
|
1462
|
|
|
1463 </list>
|
|
|
1464 </para>
|
|
|
1465
|
|
|
1466 <para>
|
|
|
1467 A log message is formatted in a buffer of size
|
|
|
1468 <literal>NGX_MAX_ERROR_STR</literal> (currently, 2048 bytes) on stack.
|
|
|
1469 The message is prepended with error level, process PID, connection id (stored
|
|
|
1470 in <literal>log->connection</literal>) and system error text.
|
|
|
1471 For non-debug messages <literal>log->handler</literal> is called as well to
|
|
|
1472 prepend more specific information to the log message.
|
|
|
1473 HTTP module sets <literal>ngx_http_log_error()</literal> function as log
|
|
|
1474 handler to log client and server addresses, current action (stored in
|
|
|
1475 <literal>log->action</literal>), client request line, server name etc.
|
|
|
1476 </para>
|
|
|
1477
|
|
|
1478 <para>
|
|
|
1479 Example:
|
|
|
1480 </para>
|
|
|
1481
|
|
|
1482
|
|
|
1483 <programlisting>
|
|
|
1484 /* specify what is currently done */
|
|
|
1485 log->action = "sending mp4 to client”;
|
|
|
1486
|
|
|
1487 /* error and debug log */
|
|
|
1488 ngx_log_error(NGX_LOG_INFO, c->log, 0, "client prematurely
|
|
|
1489 closed connection”);
|
|
|
1490
|
|
|
1491 ngx_log_debug2(NGX_LOG_DEBUG_HTTP, mp4->file.log, 0,
|
|
|
1492 "mp4 start:%ui, length:%ui”, mp4->start, mp4->length);
|
|
|
1493 </programlisting>
|
|
|
1494
|
|
|
1495 <para>
|
|
|
1496 Logging result:
|
|
|
1497 </para>
|
|
|
1498
|
|
|
1499
|
|
|
1500 <programlisting>
|
|
|
1501 2016/09/16 22:08:52 [info] 17445#0: *1 client prematurely closed connection while
|
|
|
1502 sending mp4 to client, client: 127.0.0.1, server: , request: "GET /file.mp4 HTTP/1.1”
|
|
|
1503 2016/09/16 23:28:33 [debug] 22140#0: *1 mp4 start:0, length:10000
|
|
|
1504 </programlisting>
|
|
|
1505
|
|
|
1506 </section>
|
|
|
1507
|
|
|
1508
|
|
|
1509 <section name="Cycle" id="cycle">
|
|
|
1510
|
|
|
1511 <para>
|
|
|
1512 Cycle object keeps nginx runtime context, created from a specific
|
|
|
1513 configuration.
|
|
|
1514 The type of the cycle is <literal>ngx_cycle_t</literal>.
|
|
|
1515 Upon configuration reload a new cycle is created from the new version of nginx
|
|
|
1516 configuration.
|
|
|
1517 The old cycle is usually deleted after a new one is successfully created.
|
|
|
1518 Currently active cycle is held in the <literal>ngx_cycle</literal> global
|
|
|
1519 variable and is inherited by newly started nginx workers.
|
|
|
1520 </para>
|
|
|
1521
|
|
|
1522 <para>
|
|
|
1523 A cycle is created by the function <literal>ngx_init_cycle()</literal>.
|
|
|
1524 The function receives the old cycle as the argument.
|
|
|
1525 It's used to locate the configuration file and inherit as much resources as
|
|
|
1526 possible from the old cycle to keep nginx running smoothly.
|
|
|
1527 When nginx starts, a fake cycle called "init cycle" is created and is then
|
|
|
1528 replaced by a normal cycle, built from configuration.
|
|
|
1529 </para>
|
|
|
1530
|
|
|
1531 <para>
|
|
|
1532 Some members of the cycle:
|
|
|
1533 </para>
|
|
|
1534
|
|
|
1535 <para>
|
|
|
1536 <list type="bullet">
|
|
|
1537
|
|
|
1538 <listitem>
|
|
|
1539 <literal>pool</literal> - cycle pool. Created for each new cycle
|
|
|
1540 </listitem>
|
|
|
1541
|
|
|
1542 <listitem>
|
|
|
1543 <literal>log</literal> - cycle log. Initially, this log is inherited from the
|
|
|
1544 old cycle.
|
|
|
1545 After reading configuration, this member is set to point to
|
|
|
1546 <literal>new_log</literal>
|
|
|
1547 </listitem>
|
|
|
1548
|
|
|
1549 <listitem>
|
|
|
1550 <literal>new_log</literal> - cycle log, created by the configuration.
|
|
|
1551 It's affected by the root scope <literal>error_log</literal> directive
|
|
|
1552 </listitem>
|
|
|
1553
|
|
|
1554 <listitem>
|
|
|
1555 <literal>connections</literal>, <literal>connections_n</literal> - per-worker
|
|
|
1556 array of connections of type <literal>ngx_connection_t</literal>, created by
|
|
|
1557 the event module while initializing each nginx worker.
|
|
|
1558 The number of connections is set by the <literal>worker_connections</literal>
|
|
|
1559 directive
|
|
|
1560 </listitem>
|
|
|
1561
|
|
|
1562 <listitem>
|
|
|
1563 <literal>free_connections</literal>,
|
|
|
1564 <literal>free_connections_n</literal> - the and number of currently available
|
|
|
1565 connections.
|
|
|
1566 If no connections are available, nginx worker refuses to accept new clients
|
|
|
1567 </listitem>
|
|
|
1568
|
|
|
1569 <listitem>
|
|
|
1570 <literal>files</literal>, <literal>files_n</literal> - array for mapping file
|
|
|
1571 descriptors to nginx connections.
|
|
|
1572 This mapping is used by the event modules, having the
|
|
|
1573 <literal>NGX_USE_FD_EVENT</literal> flag (currently, it's poll and devpoll)
|
|
|
1574 </listitem>
|
|
|
1575
|
|
|
1576 <listitem>
|
|
|
1577 <literal>conf_ctx</literal> - array of core module configurations.
|
|
|
1578 The configurations are created and filled while reading nginx configuration
|
|
|
1579 files
|
|
|
1580 </listitem>
|
|
|
1581
|
|
|
1582 <listitem>
|
|
|
1583 <literal>modules</literal>, <literal>modules_n</literal> - array of modules
|
|
|
1584 <literal>ngx_module_t</literal>, both static and dynamic, loaded by current
|
|
|
1585 configuration
|
|
|
1586 </listitem>
|
|
|
1587
|
|
|
1588 <listitem>
|
|
|
1589 <literal>listening</literal> - array of listening objects
|
|
|
1590 <literal>ngx_listening_t</literal>.
|
|
|
1591 Listening objects are normally added by the the <literal>listen</literal>
|
|
|
1592 directive of different modules which call the
|
|
|
1593 <literal>ngx_create_listening()</literal> function.
|
|
|
1594 Based on listening objects, listen sockets are created by nginx
|
|
|
1595 </listitem>
|
|
|
1596
|
|
|
1597 <listitem>
|
|
|
1598 <literal>paths</literal> - array of paths <literal>ngx_path_t</literal>.
|
|
|
1599 Paths are added by calling the function <literal>ngx_add_path()</literal> from
|
|
|
1600 modules which are going to operate on certain directories.
|
|
|
1601 These directories are created by nginx after reading configuration, if missing.
|
|
|
1602 Moreover, two handlers can be added for each path:
|
|
|
1603
|
|
|
1604 <list type="bullet">
|
|
|
1605
|
|
|
1606 <listitem>
|
|
|
1607 path loader - executed only once in 60 seconds after starting or reloading
|
|
|
1608 nginx. Normally, reads the directory and stores data in nginx shared
|
|
|
1609 memory. The handler is called from a dedicated nginx process "nginx
|
|
|
1610 cache loader"
|
|
|
1611 </listitem>
|
|
|
1612
|
|
|
1613 <listitem>
|
|
|
1614 path manager - executed periodically. Normally, removes old files from the
|
|
|
1615 directory and reflects these changes in nginx memory. The handler is
|
|
|
1616 called from a dedicated nginx process "nginx cache manager"
|
|
|
1617 </listitem>
|
|
|
1618
|
|
|
1619 </list>
|
|
|
1620 </listitem>
|
|
|
1621
|
|
|
1622 <listitem>
|
|
|
1623 <literal>open_files</literal> - list of <literal>ngx_open_file_t</literal>
|
|
|
1624 objects.
|
|
|
1625 An open file object is created by calling the function
|
|
|
1626 <literal>ngx_conf_open_file()</literal>.
|
|
|
1627 After reading configuration nginx opens all files from the
|
|
|
1628 <literal>open_files</literal> list and stores file descriptors in the
|
|
|
1629 <literal>fd</literal> field of each open file object.
|
|
|
1630 The files are opened in append mode and created if missing.
|
|
|
1631 The files from this list are reopened by nginx workers upon receiving the
|
|
|
1632 reopen signal (usually it's <literal>USR1</literal>).
|
|
|
1633 In this case the <literal>fd</literal> fields are changed to new descriptors.
|
|
|
1634 The open files are currently used for logging
|
|
|
1635 </listitem>
|
|
|
1636
|
|
|
1637 <listitem>
|
|
|
1638 <literal>shared_memory</literal> - list of shared memory zones, each added by
|
|
|
1639 calling the <literal>ngx_shared_memory_add()</literal> function.
|
|
|
1640 Shared zones are mapped to the same address range in all nginx processes and
|
|
|
1641 are used to share common data, for example HTTP cache in-memory tree
|
|
|
1642 </listitem>
|
|
|
1643
|
|
|
1644 </list>
|
|
|
1645 </para>
|
|
|
1646
|
|
|
1647 </section>
|
|
|
1648
|
|
|
1649 <section name="Buffer" id="buffer">
|
|
|
1650
|
|
|
1651 <para>
|
|
|
1652 For input/output operations, nginx provides the buffer type
|
|
|
1653 <literal>ngx_buf_t</literal>.
|
|
|
1654 Normally, it's used to hold data to be written to a destination or read from a
|
|
|
1655 source.
|
|
|
1656 Buffer can reference data in memory and in file.
|
|
|
1657 Technically it's possible that a buffer references both at the same time.
|
|
|
1658 Memory for the buffer is allocated separately and is not related to the buffer
|
|
|
1659 structure <literal>ngx_buf_t</literal>.
|
|
|
1660 </para>
|
|
|
1661
|
|
|
1662 <para>
|
|
|
1663 The structure <literal>ngx_buf_t</literal> has the following fields:
|
|
|
1664 </para>
|
|
|
1665
|
|
|
1666 <para>
|
|
|
1667 <list type="bullet">
|
|
|
1668
|
|
|
1669 <listitem>
|
|
|
1670 <literal>start</literal>, <literal>end</literal> - the boundaries of memory
|
|
|
1671 block, allocated for the buffer
|
|
|
1672 </listitem>
|
|
|
1673
|
|
|
1674 <listitem>
|
|
|
1675 <literal>pos</literal>, <literal>last</literal> - memory buffer boundaries,
|
|
|
1676 normally a subrange of <literal>start</literal> .. <literal>end</literal>
|
|
|
1677 </listitem>
|
|
|
1678
|
|
|
1679 <listitem>
|
|
|
1680 <literal>file_pos</literal>, <literal>file_last</literal> - file buffer
|
|
|
1681 boundaries, these are offsets from the beginning of the file
|
|
|
1682 </listitem>
|
|
|
1683
|
|
|
1684 <listitem>
|
|
|
1685 <literal>tag</literal> - unique value, used to distinguish buffers, created by
|
|
|
1686 different nginx module, usually, for the purpose of buffer reuse
|
|
|
1687 </listitem>
|
|
|
1688
|
|
|
1689 <listitem>
|
|
|
1690 <literal>file</literal> - file object
|
|
|
1691 </listitem>
|
|
|
1692
|
|
|
1693 <listitem>
|
|
|
1694 <literal>temporary</literal> - flag, meaning that the buffer references
|
|
|
1695 writable memory
|
|
|
1696 </listitem>
|
|
|
1697
|
|
|
1698 <listitem>
|
|
|
1699 <literal>memory</literal> - flag, meaning that the buffer references read-only
|
|
|
1700 memory
|
|
|
1701 </listitem>
|
|
|
1702
|
|
|
1703 <listitem>
|
|
|
1704 <literal>in_file</literal> - flag, meaning that current buffer references data
|
|
|
1705 in a file
|
|
|
1706 </listitem>
|
|
|
1707
|
|
|
1708 <listitem>
|
|
|
1709 <literal>flush</literal> - flag, meaning that all data prior to this buffer
|
|
|
1710 should be flushed
|
|
|
1711 </listitem>
|
|
|
1712
|
|
|
1713 <listitem>
|
|
|
1714 <literal>recycled</literal> - flag, meaning that the buffer can be reused and
|
|
|
1715 should be consumed as soon as possible
|
|
|
1716 </listitem>
|
|
|
1717
|
|
|
1718 <listitem>
|
|
|
1719 <literal>sync</literal> - flag, meaning that the buffer carries no data or
|
|
|
1720 special signal like <literal>flush</literal> or <literal>last_buf</literal>.
|
|
|
1721 Normally, such buffers are considered an error by nginx. This flags allows
|
|
|
1722 skipping the error checks
|
|
|
1723 </listitem>
|
|
|
1724
|
|
|
1725 <listitem>
|
|
|
1726 <literal>last_buf</literal> - flag, meaning that current buffer is the last in
|
|
|
1727 output
|
|
|
1728 </listitem>
|
|
|
1729
|
|
|
1730 <listitem>
|
|
|
1731 <literal>last_in_chain</literal> - flag, meaning that there's no more data
|
|
|
1732 buffers in a (sub)request
|
|
|
1733 </listitem>
|
|
|
1734
|
|
|
1735 <listitem>
|
|
|
1736 <literal>shadow</literal> - reference to another buffer, related to the current
|
|
|
1737 buffer. Usually current buffer uses data from the shadow buffer. Once current
|
|
|
1738 buffer is consumed, the shadow buffer should normally also be marked as
|
|
|
1739 consumed
|
|
|
1740 </listitem>
|
|
|
1741
|
|
|
1742 <listitem>
|
|
|
1743 <literal>last_shadow</literal> - flag, meaning that current buffer is the last
|
|
|
1744 buffer, referencing a particular shadow buffer
|
|
|
1745 </listitem>
|
|
|
1746
|
|
|
1747 <listitem>
|
|
|
1748 <literal>temp_file</literal> - flag, meaning that the buffer is in a temporary
|
|
|
1749 file
|
|
|
1750 </listitem>
|
|
|
1751
|
|
|
1752 </list>
|
|
|
1753 </para>
|
|
|
1754
|
|
|
1755 <para>
|
|
|
1756 For input and output buffers are linked in chains.
|
|
|
1757 Chain is a sequence of chain links <literal>ngx_chain_t</literal>, defined as
|
|
|
1758 follows:
|
|
|
1759 </para>
|
|
|
1760
|
|
|
1761
|
|
|
1762 <programlisting>
|
|
|
1763 typedef struct ngx_chain_s ngx_chain_t;
|
|
|
1764
|
|
|
1765 struct ngx_chain_s {
|
|
|
1766 ngx_buf_t *buf;
|
|
|
1767 ngx_chain_t *next;
|
|
|
1768 };
|
|
|
1769 </programlisting>
|
|
|
1770
|
|
|
1771 <para>
|
|
|
1772 Each chain link keeps a reference to its buffer and a reference to the next
|
|
|
1773 chain link.
|
|
|
1774 </para>
|
|
|
1775
|
|
|
1776 <para>
|
|
|
1777 Example of using buffers and chains:
|
|
|
1778 </para>
|
|
|
1779
|
|
|
1780
|
|
|
1781 <programlisting>
|
|
|
1782 ngx_chain_t *
|
|
|
1783 ngx_get_my_chain(ngx_pool_t *pool)
|
|
|
1784 {
|
|
|
1785 ngx_buf_t *b;
|
|
|
1786 ngx_chain_t *out, *cl, **ll;
|
|
|
1787
|
|
|
1788 /* first buf */
|
|
|
1789 cl = ngx_alloc_chain_link(pool);
|
|
|
1790 if (cl == NULL) { /* error */ }
|
|
|
1791
|
|
|
1792 b = ngx_calloc_buf(pool);
|
|
|
1793 if (b == NULL) { /* error */ }
|
|
|
1794
|
|
|
1795 b->start = (u_char *) "foo";
|
|
|
1796 b->pos = b->start;
|
|
|
1797 b->end = b->start + 3;
|
|
|
1798 b->last = b->end;
|
|
|
1799 b->memory = 1; /* read-only memory */
|
|
|
1800
|
|
|
1801 cl->buf = b;
|
|
|
1802 out = cl;
|
|
|
1803 ll = &cl->next;
|
|
|
1804
|
|
|
1805 /* second buf */
|
|
|
1806 cl = ngx_alloc_chain_link(pool);
|
|
|
1807 if (cl == NULL) { /* error */ }
|
|
|
1808
|
|
|
1809 b = ngx_create_temp_buf(pool, 3);
|
|
|
1810 if (b == NULL) { /* error */ }
|
|
|
1811
|
|
|
1812 b->last = ngx_cpymem(b->last, "foo", 3);
|
|
|
1813
|
|
|
1814 cl->buf = b;
|
|
|
1815 cl->next = NULL;
|
|
|
1816 *ll = cl;
|
|
|
1817
|
|
|
1818 return out;
|
|
|
1819 }
|
|
|
1820 </programlisting>
|
|
|
1821
|
|
|
1822 </section>
|
|
|
1823
|
|
|
1824
|
|
|
1825 <section name="Networking" id="networking">
|
|
|
1826
|
|
|
1827
|
|
|
1828 <!--
|
|
|
1829 <section name="Network data types" id="network_data_types">
|
|
|
1830
|
|
|
1831 <para>
|
|
|
1832 TBD: ngx_addr_t, ngx_url_t, ngx_socket_t, ngx_sockaddr_t, parse url, parse
|
|
|
1833 address...
|
|
|
1834 </para>
|
|
|
1835
|
|
|
1836 </section>
|
|
|
1837 -->
|
|
|
1838
|
|
|
1839 <section name="Connection" id="connection">
|
|
|
1840
|
|
|
1841 <para>
|
|
|
1842 Connection type <literal>ngx_connection_t</literal> is a wrapper around a
|
|
|
1843 socket descriptor. Some of the structure fields are:
|
|
|
1844 </para>
|
|
|
1845
|
|
|
1846 <para>
|
|
|
1847 <list type="bullet">
|
|
|
1848
|
|
|
1849 <listitem>
|
|
|
1850 <literal>fd</literal> - socket descriptor
|
|
|
1851 </listitem>
|
|
|
1852
|
|
|
1853 <listitem>
|
|
|
1854 <literal>data</literal> - arbitrary connection context.
|
|
|
1855 Normally, a pointer to a higher level object, built on top of the connection,
|
|
|
1856 like HTTP request or Stream session
|
|
|
1857 </listitem>
|
|
|
1858
|
|
|
1859 <listitem>
|
|
|
1860 <literal>read</literal>, <literal>write</literal> - read and write events for
|
|
|
1861 the connection
|
|
|
1862 </listitem>
|
|
|
1863
|
|
|
1864 <listitem>
|
|
|
1865 <literal>recv</literal>, <literal>send</literal>,
|
|
|
1866 <literal>recv_chain</literal>, <literal>send_chain</literal> - I/O operations
|
|
|
1867 for the connection
|
|
|
1868 </listitem>
|
|
|
1869
|
|
|
1870 <listitem>
|
|
|
1871 <literal>pool</literal> - connection pool
|
|
|
1872 </listitem>
|
|
|
1873
|
|
|
1874 <listitem>
|
|
|
1875 <literal>log</literal> - connection log
|
|
|
1876 </listitem>
|
|
|
1877
|
|
|
1878 <listitem>
|
|
|
1879 <literal>sockaddr</literal>, <literal>socklen</literal>,
|
|
|
1880 <literal>addr_text</literal> - remote socket address in binary and text forms
|
|
|
1881 </listitem>
|
|
|
1882
|
|
|
1883 <listitem>
|
|
|
1884 <literal>local_sockaddr</literal>, <literal>local_socklen</literal> - local
|
|
|
1885 socket address in binary form.
|
|
|
1886 Initially, these fields are empty.
|
|
|
1887 Function <literal>ngx_connection_local_sockaddr()</literal> should be used to
|
|
|
1888 get socket local address
|
|
|
1889 </listitem>
|
|
|
1890
|
|
|
1891 <listitem>
|
|
|
1892 <literal>proxy_protocol_addr</literal>, <literal>proxy_protocol_port</literal>
|
|
|
1893 - PROXY protocol client address and port, if PROXY protocol is enabled for the
|
|
|
1894 connection
|
|
|
1895 </listitem>
|
|
|
1896
|
|
|
1897 <listitem>
|
|
|
1898 <literal>ssl</literal> - nginx connection SSL context
|
|
|
1899 </listitem>
|
|
|
1900
|
|
|
1901 <listitem>
|
|
|
1902 <literal>reusable</literal> - flag, meaning, that the connection is at the
|
|
|
1903 state, when it can be reused
|
|
|
1904 </listitem>
|
|
|
1905
|
|
|
1906 <listitem>
|
|
|
1907 <literal>close</literal> - flag, meaning, that the connection is being reused
|
|
|
1908 and should be closed
|
|
|
1909 </listitem>
|
|
|
1910
|
|
|
1911 </list>
|
|
|
1912 </para>
|
|
|
1913
|
|
|
1914 <para>
|
|
|
1915 An nginx connection can transparently encapsulate SSL layer.
|
|
|
1916 In this case the connection <literal>ssl</literal> field holds a pointer to an
|
|
|
1917 <literal>ngx_ssl_connection_t</literal> structure, keeping all SSL-related data
|
|
|
1918 for the connection, including <literal>SSL_CTX</literal> and
|
|
|
1919 <literal>SSL</literal>.
|
|
|
1920 The handlers <literal>recv</literal>, <literal>send</literal>,
|
|
|
1921 <literal>recv_chain</literal>, <literal>send_chain</literal> are set as well to
|
|
|
1922 SSL functions.
|
|
|
1923 </para>
|
|
|
1924
|
|
|
1925 <para>
|
|
|
1926 The number of connections per nginx worker is limited by the
|
|
|
1927 <literal>worker_connections</literal> value.
|
|
|
1928 All connection structures are pre-created when a worker starts and stored in
|
|
|
1929 the <literal>connections</literal> field of the cycle object.
|
|
|
1930 To reach out for a connection structure, <literal>ngx_get_connection(s,
|
|
|
1931 log)</literal> function is used.
|
|
|
1932 The function receives a socket descriptor <literal>s</literal> which needs to
|
|
|
1933 be wrapped in a connection structure.
|
|
|
1934 </para>
|
|
|
1935
|
|
|
1936 <para>
|
|
|
1937 Since the number of connections per worker is limited, nginx provides a
|
|
|
1938 way to grab connections which are currently in use.
|
|
|
1939 To enable or disable reuse of a connection, function
|
|
|
1940 <literal>ngx_reusable_connection(c, reusable)</literal> is called.
|
|
|
1941 Calling <literal>ngx_reusable_connection(c, 1)</literal> sets the
|
|
|
1942 <literal>reuse</literal> flag of the connection structure and inserts the
|
|
|
1943 connection in the <literal>reusable_connections_queue</literal> of the cycle.
|
|
|
1944 Whenever <literal>ngx_get_connection()</literal> finds out there are no
|
|
|
1945 available connections in the <literal>free_connections</literal> list of the
|
|
|
1946 cycle, it calls <literal>ngx_drain_connections()</literal> to release a
|
|
|
1947 specific number of reusable connections.
|
|
|
1948 For each such connection, the <literal>close</literal> flag is set and its read
|
|
|
1949 handler is called which is supposed to free the connection by calling
|
|
|
1950 <literal>ngx_close_connection(c)</literal> and make it available for reuse.
|
|
|
1951 To exit the state when a connection can be reused
|
|
|
1952 <literal>ngx_reusable_connection(c, 0)</literal> is called.
|
|
|
1953 An example of reusable connections in nginx is HTTP client connections which
|
|
|
1954 are marked as reusable until some data is received from the client.
|
|
|
1955 </para>
|
|
|
1956
|
|
|
1957 </section>
|
|
|
1958
|
|
|
1959
|
|
|
1960 </section>
|
|
|
1961
|
|
|
1962
|
|
|
1963 <section name="Events" id="events">
|
|
|
1964
|
|
|
1965
|
|
|
1966 <section name="Event" id="event">
|
|
|
1967
|
|
|
1968 <para>
|
|
|
1969 Event object <literal>ngx_event_t</literal> in nginx provides a way to be
|
|
|
1970 notified of a specific event happening.
|
|
|
1971 </para>
|
|
|
1972
|
|
|
1973 <para>
|
|
|
1974 Some of the fields of the <literal>ngx_event_t</literal> are:
|
|
|
1975 </para>
|
|
|
1976
|
|
|
1977 <para>
|
|
|
1978 <list type="bullet">
|
|
|
1979
|
|
|
1980 <listitem>
|
|
|
1981 <literal>data</literal> - arbitrary event context, used in event handler,
|
|
|
1982 usually, a pointer to a connection, tied with the event
|
|
|
1983 </listitem>
|
|
|
1984
|
|
|
1985 <listitem>
|
|
|
1986 <literal>handler</literal> - callback function to be invoked when the event
|
|
|
1987 happens
|
|
|
1988 </listitem>
|
|
|
1989
|
|
|
1990 <listitem>
|
|
|
1991 <literal>write</literal> - flag, meaning that this is the write event.
|
|
|
1992 Used to distinguish between read and write events
|
|
|
1993 </listitem>
|
|
|
1994
|
|
|
1995 <listitem>
|
|
|
1996 <literal>active</literal> - flag, meaning that the event is registered for
|
|
|
1997 receiving I/O notifications, normally from notification mechanisms like epoll,
|
|
|
1998 kqueue, poll
|
|
|
1999 </listitem>
|
|
|
2000
|
|
|
2001 <listitem>
|
|
|
2002 <literal>ready</literal> - flag, meaning that the event has received an
|
|
|
2003 I/O notification
|
|
|
2004 </listitem>
|
|
|
2005
|
|
|
2006 <listitem>
|
|
|
2007 <literal>delayed</literal> - flag, meaning that I/O is delayed due to rate
|
|
|
2008 limiting
|
|
|
2009 </listitem>
|
|
|
2010
|
|
|
2011 <listitem>
|
|
|
2012 <literal>timer</literal> - Red-Black tree node for inserting the event into
|
|
|
2013 the timer tree
|
|
|
2014 </listitem>
|
|
|
2015
|
|
|
2016 <listitem>
|
|
|
2017 <literal>timer_set</literal> - flag, meaning that the event timer is set,
|
|
|
2018 but not yet expired
|
|
|
2019 </listitem>
|
|
|
2020
|
|
|
2021 <listitem>
|
|
|
2022 <literal>timedout</literal> - flag, meaning that the event timer has expired
|
|
|
2023 </listitem>
|
|
|
2024
|
|
|
2025 <listitem>
|
|
|
2026 <literal>eof</literal> - read event flag, meaning that the eof has happened
|
|
|
2027 while reading data
|
|
|
2028 </listitem>
|
|
|
2029
|
|
|
2030 <listitem>
|
|
|
2031 <literal>pending_eof</literal> - flag, meaning that the eof is pending on the
|
|
|
2032 socket, even though there may be some data available before it.
|
|
|
2033 The flag is delivered via <literal>EPOLLRDHUP</literal> epoll event or
|
|
|
2034 <literal>EV_EOF</literal> kqueue flag
|
|
|
2035 </listitem>
|
|
|
2036
|
|
|
2037 <listitem>
|
|
|
2038 <literal>error</literal> - flag, meaning that an error has happened while
|
|
|
2039 reading (for read event) or writing (for write event)
|
|
|
2040 </listitem>
|
|
|
2041
|
|
|
2042 <listitem>
|
|
|
2043 <literal>cancelable</literal> - timer event flag, meaning that the event
|
|
|
2044 handler should be called while performing nginx worker graceful shutdown, event
|
|
|
2045 though event timeout has not yet expired. The flag provides a way to finalize
|
|
|
2046 certain activities, for example, flush log files
|
|
|
2047 </listitem>
|
|
|
2048
|
|
|
2049 <listitem>
|
|
|
2050 <literal>posted</literal> - flag, meaning that the event is posted to queue
|
|
|
2051 </listitem>
|
|
|
2052
|
|
|
2053 <listitem>
|
|
|
2054 <literal>queue</literal> - queue node for posting the event to a queue
|
|
|
2055 </listitem>
|
|
|
2056
|
|
|
2057 </list>
|
|
|
2058 </para>
|
|
|
2059
|
|
|
2060 </section>
|
|
|
2061
|
|
|
2062
|
|
|
2063 <section name="I/O events" id="i_o_events">
|
|
|
2064
|
|
|
2065 <para>
|
|
|
2066 Each connection, received with the
|
|
|
2067 <literal>ngx_get_connection()</literal> call, has two events attached to it:
|
|
|
2068 <literal>c->read</literal> and <literal>c->write</literal>.
|
|
|
2069 These events are used to receive notifications about the socket being ready for
|
|
|
2070 reading or writing.
|
|
|
2071 All such events operate in Edge-Triggered mode, meaning that they only trigger
|
|
|
2072 notifications when the state of the socket changes.
|
|
|
2073 For example, doing a partial read on a socket will not make nginx deliver a
|
|
|
2074 repeated read notification until more data arrive in the socket.
|
|
|
2075 Even when the underlying I/O notification mechanism is essentially
|
|
|
2076 Level-Triggered (poll, select etc), nginx will turn the notifications into
|
|
|
2077 Edge-Triggered.
|
|
|
2078 To make nginx event notifications consistent across all notifications systems
|
|
|
2079 on different platforms, it's required, that the functions
|
|
|
2080 <literal>ngx_handle_read_event(rev, flags)</literal> and
|
|
|
2081 <literal>ngx_handle_read_event(wev,flags)</literal> are called after handling
|
|
|
2082 an I/O socket notification or calling any I/O functions on that socket.
|
|
|
2083 Normally, these functions are called once in the end of each read or write
|
|
|
2084 event handler.
|
|
|
2085 </para>
|
|
|
2086
|
|
|
2087 </section>
|
|
|
2088
|
|
|
2089
|
|
|
2090 <section name="Timer events" id="timer_events">
|
|
|
2091
|
|
|
2092 <para>
|
|
|
2093 An event can be set to notify a timeout expiration.
|
|
|
2094 The function <literal>ngx_add_timer(ev, timer)</literal> sets a timeout for an
|
|
|
2095 event, <literal>ngx_del_timer(ev)</literal> deletes a previously set timeout.
|
|
|
2096 Timeouts currently set for all existing events, are kept in a global timeout
|
|
|
2097 Red-Black tree <literal>ngx_event_timer_rbtree</literal>.
|
|
|
2098 The key in that tree has the type <literal>ngx_msec_t</literal> and is the time
|
|
|
2099 in milliseconds since the beginning of January 1, 1970 (modulus
|
|
|
2100 <literal>ngx_msec_t</literal> max value) at which the event should expire.
|
|
|
2101 The tree structure provides fast inserting and deleting operations, as well as
|
|
|
2102 accessing the nearest timeouts.
|
|
|
2103 The latter is used by nginx to find out for how long to wait for I/O events
|
|
|
2104 and for expiring timeout events afterwards.
|
|
|
2105 </para>
|
|
|
2106
|
|
|
2107 </section>
|
|
|
2108
|
|
|
2109
|
|
|
2110 <section name="Posted events" id="posted_events">
|
|
|
2111
|
|
|
2112 <para>
|
|
|
2113 An event can be posted which means that its handler will be called at some
|
|
|
2114 point later within the current event loop iteration.
|
|
|
2115 Posting events is a good practice for simplifying code and escaping stack
|
|
|
2116 overflows.
|
|
|
2117 Posted events are held in a post queue.
|
|
|
2118 The macro <literal>ngx_post_event(ev, q)</literal> posts the event
|
|
|
2119 <literal>ev</literal> to the post queue <literal>q</literal>.
|
|
|
2120 Macro <literal>ngx_delete_posted_event(ev)</literal> deletes the event
|
|
|
2121 <literal>ev</literal> from whatever queue it's currently posted.
|
|
|
2122 Normally, events are posted to the <literal>ngx_posted_events</literal> queue.
|
|
|
2123 This queue is processed late in the event loop - after all I/O and timer
|
|
|
2124 events are already handled.
|
|
|
2125 The function <literal>ngx_event_process_posted()</literal> is called to process
|
|
|
2126 an event queue.
|
|
|
2127 This function calls event handlers until the queue is not empty. This means
|
|
|
2128 that a posted event handler can post more events to be processed within the
|
|
|
2129 current event loop iteration.
|
|
|
2130 </para>
|
|
|
2131
|
|
|
2132 <para>
|
|
|
2133 Example:
|
|
|
2134 </para>
|
|
|
2135
|
|
|
2136
|
|
|
2137 <programlisting>
|
|
|
2138 void
|
|
|
2139 ngx_my_connection_read(ngx_connection_t *c)
|
|
|
2140 {
|
|
|
2141 ngx_event_t *rev;
|
|
|
2142
|
|
|
2143 rev = c->read;
|
|
|
2144
|
|
|
2145 ngx_add_timer(rev, 1000);
|
|
|
2146
|
|
|
2147 rev->handler = ngx_my_read_handler;
|
|
|
2148
|
|
|
2149 ngx_my_read(rev);
|
|
|
2150 }
|
|
|
2151
|
|
|
2152
|
|
|
2153 void
|
|
|
2154 ngx_my_read_handler(ngx_event_t *rev)
|
|
|
2155 {
|
|
|
2156 ssize_t n;
|
|
|
2157 ngx_connection_t *c;
|
|
|
2158 u_char buf[256];
|
|
|
2159
|
|
|
2160 if (rev->timedout) { /* timeout expired */ }
|
|
|
2161
|
|
|
2162 c = rev->data;
|
|
|
2163
|
|
|
2164 while (rev->ready) {
|
|
|
2165 n = c->recv(c, buf, sizeof(buf));
|
|
|
2166
|
|
|
2167 if (n == NGX_AGAIN) {
|
|
|
2168 break;
|
|
|
2169 }
|
|
|
2170
|
|
|
2171 if (n == NGX_ERROR) { /* error */ }
|
|
|
2172
|
|
|
2173 /* process buf */
|
|
|
2174 }
|
|
|
2175
|
|
|
2176 if (ngx_handle_read_event(rev, 0) != NGX_OK) { /* error */ }
|
|
|
2177 }
|
|
|
2178 </programlisting>
|
|
|
2179
|
|
|
2180 </section>
|
|
|
2181
|
|
|
2182
|
|
|
2183 <section name="Event loop" id="event_loop">
|
|
|
2184
|
|
|
2185 <para>
|
|
|
2186 All nginx processes which do I/O, have an event loop.
|
|
|
2187 The only type of process which does not have I/O, is nginx master process which
|
|
|
2188 spends most of its time in <literal>sigsuspend()</literal> call waiting for
|
|
|
2189 signals to arrive.
|
|
|
2190 Event loop is implemented in <literal>ngx_process_events_and_timers()</literal>
|
|
|
2191 function.
|
|
|
2192 This function is called repeatedly until the process exits.
|
|
|
2193 It has the following stages:
|
|
|
2194 </para>
|
|
|
2195
|
|
|
2196 <para>
|
|
|
2197 <list type="bullet">
|
|
|
2198
|
|
|
2199 <listitem>
|
|
|
2200 find nearest timeout by calling <literal>ngx_event_find_timer()</literal>.
|
|
|
2201 This function finds the leftmost timer tree node and returns the number of
|
|
|
2202 milliseconds until that node expires
|
|
|
2203 </listitem>
|
|
|
2204
|
|
|
2205 <listitem>
|
|
|
2206 process I/O events by calling a handler, specific to event notification
|
|
|
2207 mechanism, chosen by nginx configuration.
|
|
|
2208 This handler waits for at least one I/O event to happen, but no longer, than
|
|
|
2209 the nearest timeout.
|
|
|
2210 For each read or write event which has happened, the <literal>ready</literal>
|
|
|
2211 flag is set and its handler is called.
|
|
|
2212 For Linux, normally, the <literal>ngx_epoll_process_events()</literal> handler
|
|
|
2213 is used which calls <literal>epoll_wait()</literal> to wait for I/O events
|
|
|
2214 </listitem>
|
|
|
2215
|
|
|
2216 <listitem>
|
|
|
2217 expire timers by calling <literal>ngx_event_expire_timers()</literal>.
|
|
|
2218 The timer tree is iterated from the leftmost element to the right until a not
|
|
|
2219 yet expired timeout is found.
|
|
|
2220 For each expired node the <literal>timedout</literal> event flag is set,
|
|
|
2221 <literal>timer_set</literal> flag is reset, and the event handler is called
|
|
|
2222 </listitem>
|
|
|
2223
|
|
|
2224 <listitem>
|
|
|
2225 process posted events by calling <literal>ngx_event_process_posted()</literal>.
|
|
|
2226 The function repeatedly removes the first element from the posted events
|
|
|
2227 queue and calls its handler until the queue gets empty
|
|
|
2228 </listitem>
|
|
|
2229
|
|
|
2230 </list>
|
|
|
2231 </para>
|
|
|
2232
|
|
|
2233 <para>
|
|
|
2234 All nginx processes handle signals as well.
|
|
|
2235 Signal handlers only set global variables which are checked after the
|
|
|
2236 <literal>ngx_process_events_and_timers()</literal> call.
|
|
|
2237 </para>
|
|
|
2238
|
|
|
2239 </section>
|
|
|
2240
|
|
|
2241
|
|
|
2242 </section>
|
|
|
2243
|
|
|
2244
|
|
|
2245 <section name="Processes" id="processes">
|
|
|
2246
|
|
|
2247 <para>
|
|
|
2248 There are several types of processes in nginx.
|
|
|
2249 The type of current process is kept in the <literal>ngx_process</literal>
|
|
|
2250 global variable:
|
|
|
2251 </para>
|
|
|
2252
|
|
|
2253 <list type="bullet">
|
|
|
2254
|
|
|
2255 <listitem>
|
|
|
2256
|
|
|
2257 <para>
|
|
|
2258 <literal>NGX_PROCESS_MASTER</literal> - the master process runs the
|
|
|
2259 <literal>ngx_master_process_cycle()</literal> function.
|
|
|
2260 Master process does not have any I/O and responds only to signals.
|
|
|
2261 It reads configuration, creates cycles, starts and controls child processes
|
|
|
2262 </para>
|
|
|
2263
|
|
|
2264
|
|
|
2265 </listitem>
|
|
|
2266
|
|
|
2267 <listitem>
|
|
|
2268
|
|
|
2269 <para>
|
|
|
2270 <literal>NGX_PROCESS_WORKER</literal> - the worker process runs the
|
|
|
2271 <literal>ngx_worker_process_cycle()</literal> function.
|
|
|
2272 Worker processes are started by master and handle client connections.
|
|
|
2273 They also respond to signals and channel commands, sent from master
|
|
|
2274 </para>
|
|
|
2275
|
|
|
2276
|
|
|
2277 </listitem>
|
|
|
2278
|
|
|
2279 <listitem>
|
|
|
2280
|
|
|
2281 <para>
|
|
|
2282 <literal>NGX_PROCESS_SINGLE</literal> - single process is the only type
|
|
|
2283 of processes which exist in the <literal>master_process off</literal> mode.
|
|
|
2284 The cycle function for this process is
|
|
|
2285 <literal>ngx_single_process_cycle()</literal>.
|
|
|
2286 This process creates cycles and handles client connections
|
|
|
2287 </para>
|
|
|
2288
|
|
|
2289
|
|
|
2290 </listitem>
|
|
|
2291
|
|
|
2292 <listitem>
|
|
|
2293
|
|
|
2294 <para>
|
|
|
2295 <literal>NGX_PROCESS_HELPER</literal> - currently, there are two types of
|
|
|
2296 helper processes: cache manager and cache loader.
|
|
|
2297 Both of them share the same cycle function
|
|
|
2298 <literal>ngx_cache_manager_process_cycle()</literal>.
|
|
|
2299 </para>
|
|
|
2300
|
|
|
2301
|
|
|
2302 </listitem>
|
|
|
2303
|
|
|
2304 </list>
|
|
|
2305
|
|
|
2306 <para>
|
|
|
2307 All nginx processes handle the following signals:
|
|
|
2308 </para>
|
|
|
2309
|
|
|
2310 <list type="bullet">
|
|
|
2311
|
|
|
2312 <listitem>
|
|
|
2313
|
|
|
2314 <para>
|
|
|
2315 <literal>NGX_SHUTDOWN_SIGNAL</literal> (<literal>SIGQUIT</literal>) - graceful
|
|
|
2316 shutdown.
|
|
|
2317 Upon receiving this signal master process sends shutdown signal to all child
|
|
|
2318 processes.
|
|
|
2319 When no child processes are left, master destroys cycle pool and exits.
|
|
|
2320 A worker process which received this signal, closes all listening sockets and
|
|
|
2321 waits until timeout tree becomes empty, then destroys cycle pool and exits.
|
|
|
2322 A cache manager process exits right after receiving this signal.
|
|
|
2323 The variable <literal>ngx_quit</literal> is set to one after receiving this
|
|
|
2324 signal and immediately reset after being processed.
|
|
|
2325 The variable <literal>ngx_exiting</literal> is set to one when worker process
|
|
|
2326 is in shutdown state
|
|
|
2327 </para>
|
|
|
2328
|
|
|
2329
|
|
|
2330 </listitem>
|
|
|
2331
|
|
|
2332 <listitem>
|
|
|
2333
|
|
|
2334 <para>
|
|
|
2335 <literal>NGX_TERMINATE_SIGNAL</literal> (<literal>SIGTERM</literal>) -
|
|
|
2336 terminate.
|
|
|
2337 Upon receiving this signal master process sends terminate signal to all child
|
|
|
2338 processes.
|
|
|
2339 If child processes do not exit in 1 second, they are killed with the
|
|
|
2340 <literal>SIGKILL</literal> signal.
|
|
|
2341 When no child processes are left, master process destroys cycle pool and exits.
|
|
|
2342 A worker or cache manager process which received this signal destroys cycle
|
|
|
2343 pool and exits.
|
|
|
2344 The variable <literal>ngx_terminate</literal> is set to one after receiving
|
|
|
2345 this signal
|
|
|
2346 </para>
|
|
|
2347
|
|
|
2348
|
|
|
2349 </listitem>
|
|
|
2350
|
|
|
2351 <listitem>
|
|
|
2352
|
|
|
2353 <para>
|
|
|
2354 <literal>NGX_NOACCEPT_SIGNAL</literal> (<literal>SIGWINCH</literal>)
|
|
|
2355 - gracefully shut down worker processes
|
|
|
2356 </para>
|
|
|
2357
|
|
|
2358
|
|
|
2359 </listitem>
|
|
|
2360
|
|
|
2361 <listitem>
|
|
|
2362
|
|
|
2363 <para>
|
|
|
2364 <literal>NGX_RECONFIGURE_SIGNAL</literal> (<literal>SIGHUP</literal>) -
|
|
|
2365 reconfigure.
|
|
|
2366 Upon receiving this signal master process creates a new cycle from
|
|
|
2367 configuration file.
|
|
|
2368 If the new cycle was created successfully, the old cycle is deleted and new
|
|
|
2369 child processes are started.
|
|
|
2370 Meanwhile, the old processes receive the shutdown signal.
|
|
|
2371 In single-process mode, nginx creates a new cycle as well, but keeps the old
|
|
|
2372 one until all clients, tied to the old cycle, are gone.
|
|
|
2373 Worker and helper processes ignore this signal
|
|
|
2374 </para>
|
|
|
2375
|
|
|
2376
|
|
|
2377 </listitem>
|
|
|
2378
|
|
|
2379 <listitem>
|
|
|
2380
|
|
|
2381 <para>
|
|
|
2382 <literal>NGX_REOPEN_SIGNAL</literal> (<literal>SIGUSR1</literal>) - reopen
|
|
|
2383 files.
|
|
|
2384 Master process passes this signal to workers.
|
|
|
2385 Worker processes reopen all <literal>open_files</literal> from the cycle
|
|
|
2386 </para>
|
|
|
2387
|
|
|
2388
|
|
|
2389 </listitem>
|
|
|
2390
|
|
|
2391 <listitem>
|
|
|
2392
|
|
|
2393 <para>
|
|
|
2394 <literal>NGX_CHANGEBIN_SIGNAL</literal> (<literal>SIGUSR2</literal>) - change
|
|
|
2395 nginx binary.
|
|
|
2396 Master process starts a new nginx binary and passes there a list of all listen
|
|
|
2397 sockets.
|
|
|
2398 The list is passed in the environment variable <literal>"NGINX"</literal> in
|
|
|
2399 text format, where descriptor numbers separated with semicolons.
|
|
|
2400 A new nginx instance reads that variable and adds the sockets to its init
|
|
|
2401 cycle.
|
|
|
2402 Other processes ignore this signal
|
|
|
2403 </para>
|
|
|
2404
|
|
|
2405
|
|
|
2406 </listitem>
|
|
|
2407
|
|
|
2408 </list>
|
|
|
2409
|
|
|
2410 <para>
|
|
|
2411 While all nginx worker processes are able to receive and properly handle POSIX
|
|
|
2412 signals, master process normally does not pass any signals to workers and
|
|
|
2413 helpers with the standard <literal>kill()</literal> syscall.
|
|
|
2414 Instead, nginx uses inter-process channels which allow sending messages between
|
|
|
2415 all nginx processes.
|
|
|
2416 Currently, however, messages are only sent from master to its children.
|
|
|
2417 Those messages carry the same signals.
|
|
|
2418 The channels are socketpairs with their ends in different processes.
|
|
|
2419 </para>
|
|
|
2420
|
|
|
2421 <para>
|
|
|
2422 When running nginx binary, several values can be specified next to
|
|
|
2423 <literal>-s</literal> parameter.
|
|
|
2424 Those values are <literal>stop</literal>, <literal>quit</literal>,
|
|
|
2425 <literal>reopen</literal>, <literal>reload</literal>.
|
|
|
2426 They are converted to signals <literal>NGX_TERMINATE_SIGNAL</literal>,
|
|
|
2427 <literal>NGX_SHUTDOWN_SIGNAL</literal>, <literal>NGX_REOPEN_SIGNAL</literal>
|
|
|
2428 and <literal>NGX_RECONFIGURE_SIGNAL</literal> and sent to the nginx master
|
|
|
2429 process, whose pid is read from nginx pid file.
|
|
|
2430 </para>
|
|
|
2431
|
|
|
2432 </section>
|
|
|
2433
|
|
|
2434 </article>
|
