Mercurial > hg > nginx-site
comparison xml/en/docs/dev/development_guide.xml @ 1993:98b713b0a9fa
Language and style fixes in development guide.
author | Roman Arutyunyan <arut@nginx.com> |
---|---|
date | Tue, 30 May 2017 14:30:04 +0300 |
parents | 7660d6390a9d |
children | effdf0747a05 |
comparison
equal
deleted
inserted
replaced
1992:e92780d00a6d | 1993:98b713b0a9fa |
---|---|
14 <section name="Introduction" id="introduction"> | 14 <section name="Introduction" id="introduction"> |
15 | 15 |
16 | 16 |
17 <section name="Code layout" id="code_layout"> | 17 <section name="Code layout" id="code_layout"> |
18 | 18 |
19 <para> | |
20 <list type="bullet"> | 19 <list type="bullet"> |
21 <listitem> | 20 <listitem> |
22 <literal>auto</literal> — build scripts | 21 <literal>auto</literal> — Build scripts |
23 </listitem> | 22 </listitem> |
24 | 23 |
25 <listitem> | 24 <listitem> |
26 <literal>src</literal> | 25 <literal>src</literal> |
27 | 26 |
28 <list type="bullet"> | 27 <list type="bullet"> |
29 | 28 |
30 <listitem> | 29 <listitem> |
31 <literal>core</literal> — basic types and functions — string, array, log, | 30 <literal>core</literal> — Basic types and functions — string, array, log, |
32 pool etc | 31 pool, etc. |
33 </listitem> | 32 </listitem> |
34 | 33 |
35 <listitem> | 34 <listitem> |
36 <literal>event</literal> — event core | 35 <literal>event</literal> — Event core |
37 | 36 |
38 <list type="bullet"> | 37 <list type="bullet"> |
39 | 38 |
40 <listitem> | 39 <listitem> |
41 <literal>modules</literal> — event notification modules: epoll, kqueue, | 40 <literal>modules</literal> — Event notification modules: |
42 select etc | 41 <literal>epoll</literal>, <literal>kqueue</literal>, <literal>select</literal> |
42 etc. | |
43 </listitem> | 43 </listitem> |
44 | 44 |
45 </list> | 45 </list> |
46 | 46 |
47 </listitem> | 47 </listitem> |
48 | 48 |
49 <listitem> | 49 <listitem> |
50 <literal>http</literal> — core HTTP module and common code | 50 <literal>http</literal> — Core HTTP module and common code |
51 | 51 |
52 <list type="bullet"> | 52 <list type="bullet"> |
53 | 53 |
54 <listitem> | 54 <listitem> |
55 <literal>modules</literal> — other HTTP modules | 55 <literal>modules</literal> — Other HTTP modules |
56 </listitem> | 56 </listitem> |
57 | 57 |
58 <listitem> | 58 <listitem> |
59 <literal>v2</literal> — HTTPv2 | 59 <literal>v2</literal> — HTTP/2 |
60 </listitem> | 60 </listitem> |
61 | 61 |
62 </list> | 62 </list> |
63 | 63 |
64 </listitem> | 64 </listitem> |
65 | 65 |
66 <listitem> | 66 <listitem> |
67 <literal>mail</literal> — mail modules | 67 <literal>mail</literal> — Mail modules |
68 </listitem> | 68 </listitem> |
69 | 69 |
70 <listitem> | 70 <listitem> |
71 <literal>os</literal> — platform-specific code | 71 <literal>os</literal> — Platform-specific code |
72 | 72 |
73 <list type="bullet"> | 73 <list type="bullet"> |
74 | 74 |
75 <listitem> | 75 <listitem> |
76 <literal>unix</literal> | 76 <literal>unix</literal> |
83 </list> | 83 </list> |
84 | 84 |
85 </listitem> | 85 </listitem> |
86 | 86 |
87 <listitem> | 87 <listitem> |
88 <literal>stream</literal> — stream modules | 88 <literal>stream</literal> — Stream modules |
89 </listitem> | 89 </listitem> |
90 | 90 |
91 </list> | 91 </list> |
92 | 92 |
93 </listitem> | 93 </listitem> |
94 | 94 |
95 </list> | 95 </list> |
96 </para> | |
97 | 96 |
98 </section> | 97 </section> |
99 | 98 |
100 | 99 |
101 <section name="Include files" id="include_files"> | 100 <section name="Include files" id="include_files"> |
102 | 101 |
103 <para> | 102 <para> |
104 Each nginx file should start with including the following two files: | 103 The following two <literal>#include</literal> statements must appear at the |
105 </para> | 104 beginning of every nginx file: |
106 | 105 </para> |
107 | 106 |
108 <programlisting> | 107 <programlisting> |
109 #include <ngx_config.h> | 108 #include <ngx_config.h> |
110 #include <ngx_core.h> | 109 #include <ngx_core.h> |
111 </programlisting> | 110 </programlisting> |
141 | 140 |
142 | 141 |
143 <section name="Integers" id="integers"> | 142 <section name="Integers" id="integers"> |
144 | 143 |
145 <para> | 144 <para> |
146 For general purpose, nginx code uses the following two integer types | 145 For general purposes, nginx code uses two integer types, |
147 <literal>ngx_int_t</literal> and <literal>ngx_uint_t</literal> which are | 146 <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>. | 147 typedefs for <literal>intptr_t</literal> and <literal>uintptr_t</literal> |
148 respectively. | |
149 </para> | 149 </para> |
150 | 150 |
151 </section> | 151 </section> |
152 | 152 |
153 | 153 |
155 | 155 |
156 <para> | 156 <para> |
157 Most functions in nginx return the following codes: | 157 Most functions in nginx return the following codes: |
158 </para> | 158 </para> |
159 | 159 |
160 <para> | |
161 <list type="bullet"> | 160 <list type="bullet"> |
162 | 161 |
163 <listitem> | 162 <listitem> |
164 <literal>NGX_OK</literal> — operation succeeded | 163 <literal>NGX_OK</literal> — Operation succeeded. |
165 </listitem> | 164 </listitem> |
166 | 165 |
167 <listitem> | 166 <listitem> |
168 <literal>NGX_ERROR</literal> — operation failed | 167 <literal>NGX_ERROR</literal> — Operation failed. |
169 </listitem> | 168 </listitem> |
170 | 169 |
171 <listitem> | 170 <listitem> |
172 <literal>NGX_AGAIN</literal> — operation incomplete, function should be called | 171 <literal>NGX_AGAIN</literal> — Operation incomplete; call the function again. |
173 again | 172 </listitem> |
174 </listitem> | 173 |
175 | 174 <listitem> |
176 <listitem> | 175 <literal>NGX_DECLINED</literal> — Operation rejected, for example, because it is |
177 <literal>NGX_DECLINED</literal> — operation rejected, for example, if disabled | 176 disabled in the configuration. This is never an error. |
178 in configuration. This is never an error | 177 </listitem> |
179 </listitem> | 178 |
180 | 179 <listitem> |
181 <listitem> | 180 <literal>NGX_BUSY</literal> — Resource is not available. |
182 <literal>NGX_BUSY</literal> — resource is not available | 181 </listitem> |
183 </listitem> | 182 |
184 | 183 <listitem> |
185 <listitem> | 184 <literal>NGX_DONE</literal> — Operation complete or continued elsewhere. |
186 <literal>NGX_DONE</literal> — operation done or continued elsewhere. | 185 Also used as an alternative success code. |
187 Also used as an alternative success code | 186 </listitem> |
188 </listitem> | 187 |
189 | 188 <listitem> |
190 <listitem> | 189 <literal>NGX_ABORT</literal> — Function was aborted. |
191 <literal>NGX_ABORT</literal> — function was aborted. | 190 Also used as an alternative error code. |
192 Also used as an alternative error code | |
193 </listitem> | 191 </listitem> |
194 | 192 |
195 </list> | 193 </list> |
196 </para> | |
197 | 194 |
198 </section> | 195 </section> |
199 | 196 |
200 | 197 |
201 <section name="Error handling" id="error_handling"> | 198 <section name="Error handling" id="error_handling"> |
202 | 199 |
203 <para> | 200 <para> |
204 For getting the last system error code, the <literal>ngx_errno</literal> macro | 201 The <literal>ngx_errno</literal> macro returns the last system error code. |
205 is available. | |
206 It's mapped to <literal>errno</literal> on POSIX platforms and to | 202 It's mapped to <literal>errno</literal> on POSIX platforms and to |
207 <literal>GetLastError()</literal> call in Windows. | 203 <literal>GetLastError()</literal> call in Windows. |
208 For getting the last socket error number, the | 204 The <literal>ngx_socket_errno</literal> macro returns the last socket error |
209 <literal>ngx_socket_errno</literal> macro is available. | 205 number. |
210 It's mapped to <literal>errno</literal> on POSIX systems as well, | 206 Like the <literal>ngx_errno</literal> macro, it's mapped to |
211 and to <literal>WSAGetLastError()</literal> call on Windows. | 207 <literal>errno</literal> on POSIX platforms. |
212 For performance reasons the values of <literal>ngx_errno</literal> or | 208 It's mapped to the <literal>WSAGetLastError()</literal> call on Windows. |
213 <literal>ngx_socket_errno</literal> should not be accessed more than | 209 Accessing the values of <literal>ngx_errno</literal> or |
214 once in a row. | 210 <literal>ngx_socket_errno</literal> more than once in a row can cause |
215 The error value should be stored in a local variable of type | 211 performance issues. |
216 <literal>ngx_err_t</literal> for using multiple times, if required. | 212 If the error value might be used multiple times, store it in a local variable |
217 For setting errors, <literal>ngx_set_errno(errno)</literal> and | 213 of type <literal>ngx_err_t</literal>. |
218 <literal>ngx_set_socket_errno(errno)</literal> macros are available. | 214 To set errors, use the <literal>ngx_set_errno(errno)</literal> and |
219 </para> | 215 <literal>ngx_set_socket_errno(errno)</literal> macros. |
220 | 216 </para> |
221 <para> | 217 |
222 The values of <literal>ngx_errno</literal> or | 218 <para> |
223 <literal>ngx_socket_errno</literal> can be passed to logging functions | 219 The values of <literal>ngx_errno</literal> and |
220 <literal>ngx_socket_errno</literal> can be passed to the logging functions | |
224 <literal>ngx_log_error()</literal> and <literal>ngx_log_debugX()</literal>, in | 221 <literal>ngx_log_error()</literal> and <literal>ngx_log_debugX()</literal>, in |
225 which case system error text is added to the log message. | 222 which case system error text is added to the log message. |
226 </para> | 223 </para> |
227 | 224 |
228 <para> | 225 <para> |
262 | 259 |
263 | 260 |
264 <section name="Overview" id="overview"> | 261 <section name="Overview" id="overview"> |
265 | 262 |
266 <para> | 263 <para> |
267 For C strings, nginx code uses unsigned character type pointer | 264 For C strings, nginx uses the unsigned character type pointer |
268 <literal>u_char *</literal>. | 265 <literal>u_char *</literal>. |
269 </para> | 266 </para> |
270 | 267 |
271 <para> | 268 <para> |
272 The nginx string type <literal>ngx_str_t</literal> is defined as follows: | 269 The nginx string type <literal>ngx_str_t</literal> is defined as follows: |
279 u_char *data; | 276 u_char *data; |
280 } ngx_str_t; | 277 } ngx_str_t; |
281 </programlisting> | 278 </programlisting> |
282 | 279 |
283 <para> | 280 <para> |
284 The <literal>len</literal> field holds the string length, | 281 The <literal>len</literal> field holds the string length and |
285 <literal>data</literal> holds the string data. | 282 <literal>data</literal> holds the string data. |
286 The string, held in <literal>ngx_str_t</literal>, may or may not be | 283 The string, held in <literal>ngx_str_t</literal>, may or may not be |
287 null-terminated after the <literal>len</literal> bytes. | 284 null-terminated after the <literal>len</literal> bytes. |
288 In most cases it’s not. | 285 In most cases it’s not. |
289 However, in certain parts of code (for example, when parsing configuration), | 286 However, in certain parts of the code (for example, when parsing configuration), |
290 <literal>ngx_str_t</literal> objects are known to be null-terminated, and that | 287 <literal>ngx_str_t</literal> objects are known to be null-terminated, which |
291 knowledge is used to simplify string comparison and makes it easier to pass | 288 simplifies string comparison and makes it easier to pass the strings to |
292 those strings to syscalls. | 289 syscalls. |
293 </para> | 290 </para> |
294 | 291 |
295 <para> | 292 <para> |
296 A number of string operations are provided in nginx. | 293 The string operations in nginx are declared in |
297 They are declared in <path>src/core/ngx_string.h</path>. | 294 <path>src/core/ngx_string.h</path> |
298 Some of them are wrappers around standard C functions: | 295 Some of them are wrappers around standard C functions: |
299 </para> | 296 </para> |
300 | 297 |
301 <para> | 298 <para> |
302 <list type="bullet"> | 299 <list type="bullet"> |
340 </list> | 337 </list> |
341 | 338 |
342 </para> | 339 </para> |
343 | 340 |
344 <para> | 341 <para> |
345 Some nginx-specific string functions: | 342 Other string functions are nginx-specific |
346 </para> | 343 </para> |
347 | 344 |
348 <para> | 345 <para> |
349 <list type="bullet"> | 346 <list type="bullet"> |
350 | 347 |
351 <listitem> | 348 <listitem> |
352 <literal>ngx_memzero()</literal> fills memory with zeroes | 349 <literal>ngx_memzero()</literal> — Fills memory with zeroes. |
353 </listitem> | 350 </listitem> |
354 | 351 |
355 <listitem> | 352 <listitem> |
356 <literal>ngx_cpymem()</literal> does the same as | 353 <literal>ngx_cpymem()</literal> — Does the same as |
357 <literal>ngx_memcpy()</literal>, but returns the final destination address | 354 <literal>ngx_memcpy()</literal>, but returns the final destination address |
358 This one is handy for appending multiple strings in a row | 355 This one is handy for appending multiple strings in a row. |
359 </listitem> | 356 </listitem> |
360 | 357 |
361 <listitem> | 358 <listitem> |
362 <literal>ngx_movemem()</literal> does the same as | 359 <literal>ngx_movemem()</literal> — Does the same as |
363 <literal>ngx_memmove()</literal>, but returns the final destination address. | 360 <literal>ngx_memmove()</literal>, but returns the final destination address. |
364 </listitem> | 361 </listitem> |
365 | 362 |
366 <listitem> | 363 <listitem> |
367 <literal>ngx_strlchr()</literal> searches for a character in a string, | 364 <literal>ngx_strlchr()</literal> — Searches for a character in a string, |
368 delimited by two pointers | 365 delimited by two pointers. |
369 </listitem> | 366 </listitem> |
370 </list> | 367 </list> |
371 </para> | 368 </para> |
372 | 369 |
373 <para> | 370 <para> |
374 Some case conversion and comparison functions: | 371 The following functions perform case conversion and comparison: |
375 </para> | 372 </para> |
376 | 373 |
377 <para> | 374 <para> |
378 <list type="bullet"> | 375 <list type="bullet"> |
379 | 376 |
404 | 401 |
405 | 402 |
406 <section name="Formatting" id="formatting"> | 403 <section name="Formatting" id="formatting"> |
407 | 404 |
408 <para> | 405 <para> |
409 A number of formatting functions are provided by nginx. These functions support nginx-specific types: | 406 The following formatting functions support nginx-specific types: |
410 </para> | 407 </para> |
411 | 408 |
412 | 409 |
413 <para> | 410 <para> |
414 <list type="bullet"> | 411 <list type="bullet"> |
435 | 432 |
436 </list> | 433 </list> |
437 </para> | 434 </para> |
438 | 435 |
439 <para> | 436 <para> |
440 The full list of formatting options, supported by these functions, can be found | 437 The full list of formatting options, supported by these functions is |
441 in <path>src/core/ngx_string.c</path>. Some of them are: | 438 in <path>src/core/ngx_string.c</path>. Some of them are: |
442 </para> | 439 </para> |
443 | 440 |
444 | 441 |
445 <programlisting> | 442 <list type="bullet"> |
446 %O — off_t | 443 |
447 %T — time_t | 444 <listitem> |
448 %z — size_t | 445 <literal>%O</literal> — <literal>off_t</literal> |
449 %i — ngx_int_t | 446 </listitem> |
450 %p — void * | 447 |
451 %V — ngx_str_t * | 448 <listitem> |
452 %s — u_char * (null-terminated) | 449 <literal>%T</literal> — <literal>time_t</literal> |
453 %*s — size_t + u_char * | 450 </listitem> |
454 </programlisting> | 451 |
455 | 452 <listitem> |
456 <para> | 453 <literal>%z</literal> — <literal>size_t</literal> |
457 The ‘u’ modifier makes most types unsigned, ‘X’/‘x’ convert output to hex. | 454 </listitem> |
458 </para> | 455 |
459 | 456 <listitem> |
460 <para> | 457 <literal>%i</literal> — <literal>ngx_int_t_t</literal> |
461 Example: | 458 </listitem> |
459 | |
460 <listitem> | |
461 <literal>%p</literal> — <literal>void *</literal> | |
462 </listitem> | |
463 | |
464 <listitem> | |
465 <literal>%V</literal> — <literal>ngx_str_t *</literal> | |
466 </listitem> | |
467 | |
468 <listitem> | |
469 <literal>%s</literal> — <literal>u_char *</literal> (null-terminated) | |
470 </listitem> | |
471 | |
472 <listitem> | |
473 <literal>%*s</literal> — <literal>size_t + u_char *</literal> | |
474 </listitem> | |
475 | |
476 </list> | |
477 | |
478 | |
479 <para> | |
480 You can prepend <literal>u</literal> on most types to make them unsigned. | |
481 To convert output to hex, use <literal>X</literal> or <literal>x</literal>. | |
482 </para> | |
483 | |
484 <para> | |
485 For example: | |
462 | 486 |
463 <programlisting> | 487 <programlisting> |
464 u_char buf[NGX_INT_T_LEN]; | 488 u_char buf[NGX_INT_T_LEN]; |
465 size_t len; | 489 size_t len; |
466 ngx_int_t n; | 490 ngx_int_t n; |
476 | 500 |
477 | 501 |
478 <section name="Numeric conversion" id="numeric_conversion"> | 502 <section name="Numeric conversion" id="numeric_conversion"> |
479 | 503 |
480 <para> | 504 <para> |
481 Several functions for numeric conversion are implemented in nginx: | 505 Several functions for numeric conversion are implemented in nginx. |
482 </para> | 506 The first four each convert a string of given length to a positive integer of |
483 | 507 the indicated type. |
484 <para> | 508 They return <literal>NGX_ERROR</literal> on error. |
509 | |
485 <list type="bullet"> | 510 <list type="bullet"> |
486 | 511 |
487 <listitem> | 512 <listitem> |
488 <literal>ngx_atoi(line, n)</literal> — converts a string of given length to a | 513 <literal>ngx_atoi(line, n)</literal> — <literal>ngx_int_t</literal> |
489 positive integer of type <literal>ngx_int_t</literal>. | 514 </listitem> |
490 Returns <literal>NGX_ERROR</literal> on error | 515 |
491 </listitem> | 516 <listitem> |
492 | 517 <literal>ngx_atosz(line, n)</literal> — <literal>ssize_t</literal> |
493 <listitem> | 518 </listitem> |
494 <literal>ngx_atosz(line, n)</literal> — same for <literal>ssize_t</literal> | 519 |
495 type | 520 <listitem> |
496 </listitem> | 521 <literal>ngx_atoof(line, n)</literal> — <literal>off_t</literal> |
497 | 522 </listitem> |
498 <listitem> | 523 |
499 <literal>ngx_atoof(line, n)</literal> — same for <literal>off_t</literal> | 524 <listitem> |
500 type | 525 <literal>ngx_atotm(line, n)</literal> — <literal>time_t</literal> |
501 </listitem> | 526 </listitem> |
502 | 527 |
503 <listitem> | 528 </list> |
504 <literal>ngx_atotm(line, n)</literal> — same for <literal>time_t</literal> | 529 </para> |
505 type | 530 |
506 </listitem> | 531 <para> |
507 | 532 There are two additional numeric conversion functions. |
508 <listitem> | 533 Like the first four, they return <literal>NGX_ERROR</literal> on error. |
509 <literal>ngx_atofp(line, n, point)</literal> — converts a fixed point floating | 534 |
535 <list type="bullet"> | |
536 | |
537 <listitem> | |
538 <literal>ngx_atofp(line, n, point)</literal> — Converts a fixed point floating | |
510 number of given length to a positive integer of type | 539 number of given length to a positive integer of type |
511 <literal>ngx_int_t</literal>. | 540 <literal>ngx_int_t</literal>. |
512 The result is shifted left by <literal>points</literal> decimal | 541 The result is shifted left by <literal>point</literal> decimal |
513 positions. The string representation of the number is expected to have no more | 542 positions. |
543 The string representation of the number is expected to have no more | |
514 than <literal>points</literal> fractional digits. | 544 than <literal>points</literal> fractional digits. |
515 Returns <literal>NGX_ERROR</literal> on error. For example, | 545 For example, <literal>ngx_atofp("10.5", 4, 2)</literal> returns |
516 <literal>ngx_atofp("10.5", 4, 2)</literal> returns <literal>1050</literal> | 546 <literal>1050</literal>. |
517 </listitem> | 547 </listitem> |
518 | 548 |
519 <listitem> | 549 <listitem> |
520 <literal>ngx_hextoi(line, n)</literal> — converts hexadecimal representation of | 550 <literal>ngx_hextoi(line, n)</literal> — Converts a hexadecimal representation |
521 a positive integer to <literal>ngx_int_t</literal>. Returns | 551 of a positive integer to <literal>ngx_int_t</literal>. |
522 <literal>NGX_ERROR</literal> on error | |
523 </listitem> | 552 </listitem> |
524 | 553 |
525 </list> | 554 </list> |
526 </para> | 555 </para> |
527 | 556 |
535 library. | 564 library. |
536 The corresponding header file is <path>src/core/ngx_regex.h</path>. | 565 The corresponding header file is <path>src/core/ngx_regex.h</path>. |
537 </para> | 566 </para> |
538 | 567 |
539 <para> | 568 <para> |
540 To use a regular expression for string matching, first, it needs to be | 569 To use a regular expression for string matching, it first needs to be |
541 compiled, this is usually done at configuration phase. | 570 compiled, which is usually done at the configuration phase. |
542 Note that since PCRE support is optional, all code using the interface must | 571 Note that since PCRE support is optional, all code using the interface must |
543 be protected by the surrounding <literal>NGX_PCRE</literal> macro: | 572 be protected by the surrounding <literal>NGX_PCRE</literal> macro: |
573 | |
544 <programlisting> | 574 <programlisting> |
545 #if (NGX_PCRE) | 575 #if (NGX_PCRE) |
546 ngx_regex_t *re; | 576 ngx_regex_t *re; |
547 ngx_regex_compile_t rc; | 577 ngx_regex_compile_t rc; |
548 | 578 |
564 } | 594 } |
565 | 595 |
566 re = rc.regex; | 596 re = rc.regex; |
567 #endif | 597 #endif |
568 </programlisting> | 598 </programlisting> |
569 After successful compilation, <literal>ngx_regex_compile_t</literal> structure | 599 After successful compilation, the <literal>captures</literal> and |
570 fields <literal>captures</literal> and <literal>named_captures</literal> | 600 <literal>named_captures</literal> fields in the |
571 are filled with count of all and named captures respectively found in the | 601 <literal>ngx_regex_compile_t</literal> structure contain the count of all |
572 regular expression. | 602 captures and named captures, respectively, found in the regular expression. |
573 </para> | 603 </para> |
574 | 604 |
575 <para> | 605 <para> |
576 Later, the compiled regular expression may be used to match strings against it: | 606 The compiled regular expression can then be used for matching against strings: |
577 <programlisting> | 607 <programlisting> |
578 ngx_int_t n; | 608 ngx_int_t n; |
579 int captures[(1 + rc.captures) * 3]; | 609 int captures[(1 + rc.captures) * 3]; |
580 | 610 |
581 ngx_str_t input = ngx_string("This is message 123. Codeword is 'foobar'."); | 611 ngx_str_t input = ngx_string("This is message 123. Codeword is 'foobar'."); |
590 } else { | 620 } else { |
591 /* some error */ | 621 /* some error */ |
592 ngx_log_error(NGX_LOG_ALERT, log, 0, ngx_regex_exec_n " failed: %i", n); | 622 ngx_log_error(NGX_LOG_ALERT, log, 0, ngx_regex_exec_n " failed: %i", n); |
593 } | 623 } |
594 </programlisting> | 624 </programlisting> |
595 The arguments of <literal>ngx_regex_exec()</literal> are: the compiled regular | 625 The arguments to <literal>ngx_regex_exec()</literal> are the compiled regular |
596 expression <literal>re</literal>, string to match <literal>s</literal>, | 626 expression <literal>re</literal>, the string to match <literal>s</literal>, |
597 optional array of integers to hold found <literal>captures</literal> | 627 an optional array of integers to hold any <literal>captures</literal> that are |
598 and its <literal>size</literal>. | 628 found, and the array's <literal>size</literal>. |
599 The <literal>captures</literal> array size must be a multiple of three, | 629 The size of the <literal>captures</literal> array must be a multiple of three, |
600 per requirements of the | 630 as required by the |
601 <link url="http://www.pcre.org/original/doc/html/pcreapi.html">PCRE API</link>. | 631 <link url="http://www.pcre.org/original/doc/html/pcreapi.html">PCRE API</link>. |
602 In the example, its size is calculated from a total number of captures plus | 632 In the example, the size is calculated from the total number of captures plus |
603 one for the matched string itself. | 633 <literal>1</literal>one for the matched string itself. |
604 </para> | 634 </para> |
605 | 635 |
606 <para> | 636 <para> |
607 Now, if there are matches, captures may be accessed: | 637 If there are matches, captures can be accessed as follows: |
608 <programlisting> | 638 <programlisting> |
609 u_char *p; | 639 u_char *p; |
610 size_t size; | 640 size_t size; |
611 ngx_str_t name, value; | 641 ngx_str_t name, value; |
612 | 642 |
637 </para> | 667 </para> |
638 | 668 |
639 <para> | 669 <para> |
640 The <literal>ngx_regex_exec_array()</literal> function accepts the array of | 670 The <literal>ngx_regex_exec_array()</literal> function accepts the array of |
641 <literal>ngx_regex_elt_t</literal> elements (which are just compiled regular | 671 <literal>ngx_regex_elt_t</literal> elements (which are just compiled regular |
642 expressions with associated names), a string to match and a log. | 672 expressions with associated names), a string to match, and a log. |
643 The function will apply expressions from the array to the string until | 673 The function applies expressions from the array to the string until |
644 the match is found or no more expressions are left. | 674 either a match is found or no more expressions are left. |
645 The return value is <literal>NGX_OK</literal> in case of match and | 675 The return value is <literal>NGX_OK</literal> when there is a match and |
646 <literal>NGX_DECLINED</literal> otherwise, or <literal>NGX_ERROR</literal> | 676 <literal>NGX_DECLINED</literal> otherwise, or <literal>NGX_ERROR</literal> |
647 in case of error. | 677 in case of error. |
648 </para> | 678 </para> |
649 | 679 |
650 </section> | 680 </section> |
653 | 683 |
654 | 684 |
655 <section name="Time" id="time"> | 685 <section name="Time" id="time"> |
656 | 686 |
657 <para> | 687 <para> |
658 The <literal>ngx_time_t</literal> structure represents time split into seconds | 688 The <literal>ngx_time_t</literal> structure represents time with three separate |
659 and milliseconds with specification of GMT offset: | 689 types for seconds, milliseconds, and the GMT offset: |
660 <programlisting> | 690 <programlisting> |
661 typedef struct { | 691 typedef struct { |
662 time_t sec; | 692 time_t sec; |
663 ngx_uint_t msec; | 693 ngx_uint_t msec; |
664 ngx_int_t gmtoff; | 694 ngx_int_t gmtoff; |
665 } ngx_time_t; | 695 } ngx_time_t; |
666 </programlisting> | 696 </programlisting> |
667 The <literal>ngx_tm_t</literal> is an alias for <literal>struct tm</literal> | 697 The <literal>ngx_tm_t</literal> structure is an alias for |
668 on UNIX platforms and <literal>SYSTEMTIME</literal> on Windows. | 698 <literal>struct tm</literal> on UNIX platforms and <literal>SYSTEMTIME</literal> |
669 </para> | 699 on Windows. |
670 | 700 </para> |
671 <para> | 701 |
672 To obtain current time, usually it is enough to access one of available global | 702 <para> |
673 variables, representing the cached time value in desired format. | 703 To obtain the current time, it is usually sufficient to access one of the |
674 The <literal>ngx_current_msec</literal> variable holds milliseconds elapsed | 704 available global variables, representing the cached time value in the desired |
675 since Epoch and truncated to <literal>ngx_msec_t</literal>. | 705 format. |
676 </para> | 706 For example, the <literal>ngx_current_msec</literal> variable holds the number |
677 | 707 of milliseconds elapsed since Epoch and truncated to |
678 <para> | 708 <literal>ngx_msec_t</literal>. |
679 Available string representations are: | 709 </para> |
710 | |
711 <para> | |
712 The available string representations are: | |
680 | 713 |
681 <list type="bullet"> | 714 <list type="bullet"> |
682 | 715 |
683 <listitem> | 716 <listitem> |
684 <literal>ngx_cached_err_log_time</literal> — used in error log: | 717 <literal>ngx_cached_err_log_time</literal> — Used in error log entries: |
685 "<literal>1970/09/28 12:00:00</literal>" | 718 <literal>"1970/09/28 12:00:00"</literal> |
686 </listitem> | 719 </listitem> |
687 | 720 |
688 <listitem> | 721 <listitem> |
689 <literal>ngx_cached_http_log_time</literal> — used in HTTP access log: | 722 <literal>ngx_cached_http_log_time</literal> — Used in HTTP access log entries: |
690 "<literal>28/Sep/1970:12:00:00 +0600</literal>" | 723 <literal>"28/Sep/1970:12:00:00 +0600"</literal> |
691 </listitem> | 724 </listitem> |
692 | 725 |
693 <listitem> | 726 <listitem> |
694 <literal>ngx_cached_syslog_time</literal> — used in syslog: | 727 <literal>ngx_cached_syslog_time</literal> — Used in syslog entries: |
695 "<literal>Sep 28 12:00:00</literal>" | 728 <literal>"Sep 28 12:00:00"</literal> |
696 </listitem> | 729 </listitem> |
697 | 730 |
698 <listitem> | 731 <listitem> |
699 <literal>ngx_cached_http_time</literal> — used in HTTP for headers: | 732 <literal>ngx_cached_http_time</literal> — Used in HTTP headers: |
700 "<literal>Mon, 28 Sep 1970 06:00:00 GMT</literal>" | 733 <literal>"Mon, 28 Sep 1970 06:00:00 GMT"</literal> |
701 </listitem> | 734 </listitem> |
702 | 735 |
703 <listitem> | 736 <listitem> |
704 <literal>ngx_cached_http_log_iso8601</literal> — in the ISO 8601 | 737 <literal>ngx_cached_http_log_iso8601</literal> — The ISO 8601 |
705 standard format: | 738 standard format: |
706 "<literal>1970-09-28T12:00:00+06:00</literal>" | 739 <literal>"1970-09-28T12:00:00+06:00"</literal> |
707 </listitem> | 740 </listitem> |
708 | 741 |
709 </list> | 742 </list> |
710 </para> | 743 </para> |
711 | 744 |
712 <para> | 745 <para> |
713 The <literal>ngx_time()</literal> and <literal>ngx_timeofday()</literal> macros | 746 The <literal>ngx_time()</literal> and <literal>ngx_timeofday()</literal> macros |
714 returning current value of seconds are a preferred way to access cached | 747 return the current time value in seconds and are the preferred way to access |
715 time value. | 748 the cached time value. |
716 </para> | 749 </para> |
717 | 750 |
718 <para> | 751 <para> |
719 To obtain the time explicitly, <literal>ngx_gettimeofday()</literal> may | 752 To obtain the time explicitly, use <literal>ngx_gettimeofday()</literal>, |
720 be used, which updates its argument (pointer to | 753 which updates its argument (pointer to |
721 <literal>struct timeval</literal>). | 754 <literal>struct timeval</literal>). |
722 Time is always updated when nginx returns to event loop from system calls. | 755 The time is always updated when nginx returns to the event loop from system |
756 calls. | |
723 To update the time immediately, call <literal>ngx_time_update()</literal>, | 757 To update the time immediately, call <literal>ngx_time_update()</literal>, |
724 or <literal>ngx_time_sigsafe_update()</literal> if you need it in the | 758 or <literal>ngx_time_sigsafe_update()</literal> if updating the time in the |
725 signal handler context. | 759 signal handler context. |
726 </para> | 760 </para> |
727 | 761 |
728 <para> | 762 <para> |
729 The following functions convert <literal>time_t</literal> into broken-down time | 763 The following functions convert <literal>time_t</literal> into the indicated |
730 representation, either <literal>ngx_tm_t</literal> or | 764 broken-down time representation. |
731 <literal>struct tm</literal> for those with <literal>libc</literal> prefix: | 765 The first function in each pair converts <literal>time_t</literal> to |
766 <literal>ngx_tm_t</literal> and the second (with the <literal>_libc_</literal> | |
767 infix) to <literal>struct tm</literal>: | |
732 | 768 |
733 <list type="bullet"> | 769 <list type="bullet"> |
734 | 770 |
735 <listitem> | 771 <listitem> |
736 <literal>ngx_gmtime(), ngx_libc_gmtime()</literal> — result time is UTC | 772 <literal>ngx_gmtime(), ngx_libc_gmtime()</literal> — Time expressed as UTC |
737 </listitem> | 773 </listitem> |
738 | 774 |
739 <listitem> | 775 <listitem> |
740 <literal>ngx_localtime(), ngx_libc_localtime()</literal> — result time is | 776 <literal>ngx_localtime(), ngx_libc_localtime()</literal> — Time expressed |
741 relative to the timezone | 777 relative to the local time zone |
742 </listitem> | 778 </listitem> |
743 | 779 |
744 </list> | 780 </list> |
745 | 781 |
746 The <literal>ngx_http_time(buf, time)</literal> returns string | 782 The <literal>ngx_http_time(buf, time)</literal> function returns a string |
747 representation suitable for use with HTTP headers (for example, | 783 representation suitable for use in HTTP headers (for example, |
748 "<literal>Mon, 28 Sep 1970 06:00:00 GMT</literal>"). | 784 <literal>"Mon, 28 Sep 1970 06:00:00 GMT"</literal>). |
749 Another possible conversion is provided by | 785 The <literal>ngx_http_cookie_time(buf, time)</literal> returns a string |
750 <literal>ngx_http_cookie_time(buf, time)</literal> that produces format suitable | 786 representation function returns a string representation suitable |
751 for HTTP cookies ("<literal>Thu, 31-Dec-37 23:55:55 GMT</literal>"). | 787 for HTTP cookies (<literal>"Thu, 31-Dec-37 23:55:55 GMT"</literal>). |
752 </para> | 788 </para> |
753 | 789 |
754 </section> | 790 </section> |
755 | 791 |
756 | 792 |
773 ngx_pool_t *pool; | 809 ngx_pool_t *pool; |
774 } ngx_array_t; | 810 } ngx_array_t; |
775 </programlisting> | 811 </programlisting> |
776 | 812 |
777 <para> | 813 <para> |
778 The elements of array are available through the <literal>elts</literal> field. | 814 The elements of the array are available in the <literal>elts</literal> field. |
779 The number of elements is held in the <literal>nelts</literal> field. | 815 The <literal>nelts</literal> field holds the number of elements. |
780 The <literal>size</literal> field holds the size of a single element and is set | 816 The <literal>size</literal> field holds the size of a single element and is set |
781 when initializing the array. | 817 when the array is initialized. |
782 </para> | 818 </para> |
783 | 819 |
784 <para> | 820 <para> |
785 An array can be created in a pool with the | 821 Use the <literal>ngx_array_create(pool, n, size)</literal> call to create an |
786 <literal>ngx_array_create(pool, n, size)</literal> call. | 822 array in a pool, and the <literal>ngx_array_init(array, pool, n, size)</literal> |
787 An already allocated array object can be initialized with the | 823 call to initialize an array object that has already been allocated. |
788 <literal>ngx_array_init(array, pool, n, size)</literal> call. | |
789 </para> | 824 </para> |
790 | 825 |
791 | 826 |
792 <programlisting> | 827 <programlisting> |
793 ngx_array_t *a, b; | 828 ngx_array_t *a, b; |
798 /* initialize string array for 10 elements */ | 833 /* initialize string array for 10 elements */ |
799 ngx_array_init(&b, pool, 10, sizeof(ngx_str_t)); | 834 ngx_array_init(&b, pool, 10, sizeof(ngx_str_t)); |
800 </programlisting> | 835 </programlisting> |
801 | 836 |
802 <para> | 837 <para> |
803 Adding elements to array are done with the following functions: | 838 Use the following functions to add elements to an array: |
804 </para> | 839 </para> |
805 | 840 |
806 <para> | 841 <para> |
807 <list type="bullet"> | 842 <list type="bullet"> |
808 | 843 |
818 | 853 |
819 </list> | 854 </list> |
820 </para> | 855 </para> |
821 | 856 |
822 <para> | 857 <para> |
823 If currently allocated memory is not enough for new elements, a new memory for | 858 If the currently allocated amount of memory is not large enough to accommodate |
824 elements is allocated and existing elements are copied to that memory. | 859 the new elements, a new block of memory is allocated and the existing elements |
825 The new memory block is normally twice as large, as the existing one. | 860 are copied to it. |
861 The new memory block is normally twice as large as the existing one. | |
826 </para> | 862 </para> |
827 | 863 |
828 | 864 |
829 <programlisting> | 865 <programlisting> |
830 s = ngx_array_push(a); | 866 s = ngx_array_push(a); |
835 | 871 |
836 | 872 |
837 <section name="List" id="list"> | 873 <section name="List" id="list"> |
838 | 874 |
839 <para> | 875 <para> |
840 List in nginx is a sequence of arrays, optimized for inserting a potentially | 876 In nginx a list is a sequence of arrays, optimized for inserting a potentially |
841 large number of items. The list type is defined as follows: | 877 large number of items. |
878 The <literal>ngx_list_t</literal> list type is defined as follows: | |
842 </para> | 879 </para> |
843 | 880 |
844 | 881 |
845 <programlisting> | 882 <programlisting> |
846 typedef struct { | 883 typedef struct { |
851 ngx_pool_t *pool; | 888 ngx_pool_t *pool; |
852 } ngx_list_t; | 889 } ngx_list_t; |
853 </programlisting> | 890 </programlisting> |
854 | 891 |
855 <para> | 892 <para> |
856 The actual items are stored in list parts, defined as follows: | 893 The actual items are stored in list parts, which are defined as follows: |
857 </para> | 894 </para> |
858 | 895 |
859 | 896 |
860 <programlisting> | 897 <programlisting> |
861 typedef struct ngx_list_part_s ngx_list_part_t; | 898 typedef struct ngx_list_part_s ngx_list_part_t; |
866 ngx_list_part_t *next; | 903 ngx_list_part_t *next; |
867 }; | 904 }; |
868 </programlisting> | 905 </programlisting> |
869 | 906 |
870 <para> | 907 <para> |
871 Initially, a list must be initialized by calling | 908 Before use, a list must be initialized by calling |
872 <literal>ngx_list_init(list, pool, n, size)</literal> or created by calling | 909 <literal>ngx_list_init(list, pool, n, size)</literal> or created by calling |
873 <literal>ngx_list_create(pool, n, size)</literal>. | 910 <literal>ngx_list_create(pool, n, size)</literal>. |
874 Both functions receive the size of a single item and a number of items per list | 911 Both functions take as arguments the size of a single item and a number of |
875 part. | 912 items per list part. |
876 The <literal>ngx_list_push(list)</literal> function is used to add an item to the | 913 To add an item to a list, use the <literal>ngx_list_push(list)</literal> |
877 list. Iterating over the items is done by direct accessing the list fields, as | 914 function. |
878 seen in the example: | 915 To iterate over the items, directly access the list fields as shown in the |
916 example: | |
879 </para> | 917 </para> |
880 | 918 |
881 | 919 |
882 <programlisting> | 920 <programlisting> |
883 ngx_str_t *v; | 921 ngx_str_t *v; |
918 ngx_do_smth(&v[i]); | 956 ngx_do_smth(&v[i]); |
919 } | 957 } |
920 </programlisting> | 958 </programlisting> |
921 | 959 |
922 <para> | 960 <para> |
923 The primary use for the list in nginx is HTTP input and output headers. | 961 Lists are primarily used for HTTP input and output headers. |
924 </para> | 962 </para> |
925 | 963 |
926 <para> | 964 <para> |
927 The list does not support item removal. | 965 Lists do not support item removal. |
928 However, when needed, items can internally be marked as missing without actual | 966 However, when needed, items can internally be marked as missing without actually |
929 removing from the list. | 967 being removed from the list. |
930 For example, HTTP output headers which are stored as | 968 For example, to mark HTTP output headers (which are stored as |
931 <literal>ngx_table_elt_t</literal> objects, are marked as missing by setting | 969 <literal>ngx_table_elt_t</literal> objects) as missing, set the |
932 the <literal>hash</literal> field of <literal>ngx_table_elt_t</literal> to | 970 <literal>hash</literal> field in <literal>ngx_table_elt_t</literal> to |
933 zero. Such items are explicitly skipped, when iterating over the headers. | 971 zero. |
972 Items marked in this way are explicitly skipped when the headers are iterated | |
973 over. | |
934 </para> | 974 </para> |
935 | 975 |
936 </section> | 976 </section> |
937 | 977 |
938 | 978 |
939 <section name="Queue" id="queue"> | 979 <section name="Queue" id="queue"> |
940 | 980 |
941 <para> | 981 <para> |
942 Queue in nginx is an intrusive doubly linked list, with each node defined as | 982 In nginx a queue is an intrusive doubly linked list, with each node defined as |
943 follows: | 983 follows: |
944 </para> | 984 </para> |
945 | 985 |
946 | 986 |
947 <programlisting> | 987 <programlisting> |
952 ngx_queue_t *next; | 992 ngx_queue_t *next; |
953 }; | 993 }; |
954 </programlisting> | 994 </programlisting> |
955 | 995 |
956 <para> | 996 <para> |
957 The head queue node is not linked with any data. Before using, the list head | 997 The head queue node is not linked with any data. |
958 should be initialized with <literal>ngx_queue_init(q)</literal> call. | 998 Use the <literal>ngx_queue_init(q)</literal> call to initialize the list head |
999 before use. | |
959 Queues support the following operations: | 1000 Queues support the following operations: |
960 </para> | 1001 </para> |
961 | 1002 |
962 <para> | 1003 <para> |
963 <list type="bullet"> | 1004 <list type="bullet"> |
964 | 1005 |
965 <listitem> | 1006 <listitem> |
966 <literal>ngx_queue_insert_head(h, x)</literal>, | 1007 <literal>ngx_queue_insert_head(h, x)</literal>, |
967 <literal>ngx_queue_insert_tail(h, x)</literal> — insert a new node | 1008 <literal>ngx_queue_insert_tail(h, x)</literal> — Insert a new node |
968 </listitem> | 1009 </listitem> |
969 | 1010 |
970 <listitem> | 1011 <listitem> |
971 <literal>ngx_queue_remove(x)</literal> — remove a queue node | 1012 <literal>ngx_queue_remove(x)</literal> — Remove a queue node |
972 </listitem> | 1013 </listitem> |
973 | 1014 |
974 <listitem> | 1015 <listitem> |
975 <literal>ngx_queue_split(h, q, n)</literal> — split a queue at a node, | 1016 <literal>ngx_queue_split(h, q, n)</literal> — Split a queue at a node, |
976 queue tail is returned in a separate queue | 1017 returning the queue tail in a separate queue |
977 </listitem> | 1018 </listitem> |
978 | 1019 |
979 <listitem> | 1020 <listitem> |
980 <literal>ngx_queue_add(h, n)</literal> — add second queue to the first queue | 1021 <literal>ngx_queue_add(h, n)</literal> — Add a second queue to the first queue |
981 </listitem> | 1022 </listitem> |
982 | 1023 |
983 <listitem> | 1024 <listitem> |
984 <literal>ngx_queue_head(h)</literal>, | 1025 <literal>ngx_queue_head(h)</literal>, |
985 <literal>ngx_queue_last(h)</literal> — get first or last queue node | 1026 <literal>ngx_queue_last(h)</literal> — Get first or last queue node |
986 </listitem> | 1027 </listitem> |
987 | 1028 |
988 <listitem> | 1029 <listitem> |
989 <literal>ngx_queue_sentinel(h)</literal> | 1030 <literal>ngx_queue_sentinel(h)</literal> - Get a queue sentinel object to end |
990 - get a queue sentinel object to end iteration at | 1031 iteration at |
991 </listitem> | 1032 </listitem> |
992 | 1033 |
993 <listitem> | 1034 <listitem> |
994 <literal>ngx_queue_data(q, type, link)</literal> — get reference to the beginning of a | 1035 <literal>ngx_queue_data(q, type, link)</literal> — Get a reference to the |
995 queue node data structure, considering the queue field offset in it | 1036 beginning of a queue node data structure, considering the queue field offset in |
1037 it | |
996 </listitem> | 1038 </listitem> |
997 | 1039 |
998 </list> | 1040 </list> |
999 </para> | 1041 </para> |
1000 | 1042 |
1001 <para> | 1043 <para> |
1002 Example: | 1044 An example: |
1003 </para> | 1045 </para> |
1004 | 1046 |
1005 | 1047 |
1006 <programlisting> | 1048 <programlisting> |
1007 typedef struct { | 1049 typedef struct { |
1059 } my_node_t; | 1101 } my_node_t; |
1060 </programlisting> | 1102 </programlisting> |
1061 | 1103 |
1062 <para> | 1104 <para> |
1063 To deal with a tree as a whole, you need two nodes: root and sentinel. | 1105 To deal with a tree as a whole, you need two nodes: root and sentinel. |
1064 Typically, they are added to some custom structure, thus allowing to | 1106 Typically, they are added to a custom structure, allowing you to |
1065 organize your data into a tree which leaves contain a link to or embed | 1107 organize your data into a tree in which the leaves contain a link to or embed |
1066 your data. | 1108 your data. |
1067 </para> | 1109 </para> |
1068 | 1110 |
1069 <para> | 1111 <para> |
1070 To initialize a tree: | 1112 To initialize a tree: |
1076 | 1118 |
1077 ngx_rbtree_init(&root.rbtree, &root.sentinel, insert_value_function); | 1119 ngx_rbtree_init(&root.rbtree, &root.sentinel, insert_value_function); |
1078 </programlisting> | 1120 </programlisting> |
1079 | 1121 |
1080 <para> | 1122 <para> |
1081 The <literal>insert_value_function</literal> is a function that is | 1123 To traverse a tree and insert new values, use the |
1082 responsible for traversing the tree and inserting new values into correct | 1124 "<literal>insert_value</literal>" functions. |
1083 place. | 1125 For example, the <literal>ngx_str_rbtree_insert_value</literal> function deals |
1084 For example, the <literal>ngx_str_rbtree_insert_value</literal> functions is | 1126 with the <literal>ngx_str_t</literal> type. |
1085 designed to deal with <literal>ngx_str_t</literal> type. | 1127 Its arguments are pointers to a root node of an insertion, the newly created |
1128 node to be added, and a tree sentinel. | |
1086 </para> | 1129 </para> |
1087 | 1130 |
1088 | 1131 |
1089 <programlisting> | 1132 <programlisting> |
1090 void ngx_str_rbtree_insert_value(ngx_rbtree_node_t *temp, | 1133 void ngx_str_rbtree_insert_value(ngx_rbtree_node_t *temp, |
1091 ngx_rbtree_node_t *node, | 1134 ngx_rbtree_node_t *node, |
1092 ngx_rbtree_node_t *sentinel) | 1135 ngx_rbtree_node_t *sentinel) |
1093 </programlisting> | 1136 </programlisting> |
1094 | 1137 |
1095 <para> | |
1096 Its arguments are pointers to a root node of an insertion, newly created node | |
1097 to be added, and a tree sentinel. | |
1098 </para> | |
1099 | 1138 |
1100 <para> | 1139 <para> |
1101 The traversal is pretty straightforward and can be demonstrated with the | 1140 The traversal is pretty straightforward and can be demonstrated with the |
1102 following lookup function pattern: | 1141 following lookup function pattern: |
1103 </para> | 1142 </para> |
1141 return NULL; | 1180 return NULL; |
1142 } | 1181 } |
1143 </programlisting> | 1182 </programlisting> |
1144 | 1183 |
1145 <para> | 1184 <para> |
1146 The <literal>compare()</literal> is a classic comparator function returning | 1185 The <literal>compare()</literal> function is a classic comparator function that |
1147 value less, equal or greater than zero. To speed up lookups and avoid comparing | 1186 returns a value less than, equal to, or greater than zero. |
1148 user objects that can be big, integer hash field is used. | 1187 To speed up lookups and avoid comparing user objects that can be big, an integer |
1188 hash field is used. | |
1149 </para> | 1189 </para> |
1150 | 1190 |
1151 <para> | 1191 <para> |
1152 To add a node to a tree, allocate a new node, initialize it and call | 1192 To add a node to a tree, allocate a new node, initialize it and call |
1153 <literal>ngx_rbtree_insert()</literal>: | 1193 <literal>ngx_rbtree_insert()</literal>: |
1166 | 1206 |
1167 ngx_rbtree_insert(&root->rbtree, node); | 1207 ngx_rbtree_insert(&root->rbtree, node); |
1168 </programlisting> | 1208 </programlisting> |
1169 | 1209 |
1170 <para> | 1210 <para> |
1171 to remove a node: | 1211 To remove a node, call the <literal>ngx_rbtree_delete()</literal> function: |
1172 </para> | 1212 </para> |
1173 | 1213 |
1174 | 1214 |
1175 <programlisting> | 1215 <programlisting> |
1176 ngx_rbtree_delete(&root->rbtree, node); | 1216 ngx_rbtree_delete(&root->rbtree, node); |
1180 | 1220 |
1181 <section name="Hash" id="hash"> | 1221 <section name="Hash" id="hash"> |
1182 | 1222 |
1183 <para> | 1223 <para> |
1184 Hash table functions are declared in <path>src/core/ngx_hash.h</path>. | 1224 Hash table functions are declared in <path>src/core/ngx_hash.h</path>. |
1185 Exact and wildcard matching is supported. | 1225 Both exact and wildcard matching are supported. |
1186 The latter requires extra setup and is described in a separate section below. | 1226 The latter requires extra setup and is described in a separate section below. |
1187 </para> | 1227 </para> |
1188 | 1228 |
1189 <para> | 1229 <para> |
1190 To initialize a hash, one needs to know the number of elements in advance, | 1230 Before initializing a hash, you need to know the number of elements it will |
1191 so that nginx can build the hash optimally. | 1231 hold so that nginx can build it optimally. |
1192 Two parameters that need to be configured are <literal>max_size</literal> | 1232 Two parameters that need to be configured are <literal>max_size</literal> |
1193 and <literal>bucket_size</literal>. | 1233 and <literal>bucket_size</literal>, as detailed in a separate |
1194 The details of setting up these are provided in a separate | |
1195 <link doc="../hash.xml">document</link>. | 1234 <link doc="../hash.xml">document</link>. |
1196 Usually, these two parameters are configurable by user. | 1235 They are usually configurable by the user. |
1197 Hash initialization settings are stored as the | 1236 Hash initialization settings are stored with the |
1198 <literal>ngx_hash_init_t</literal> type, | 1237 <literal>ngx_hash_init_t</literal> type, and the hash itself is |
1199 and the hash itself is <literal>ngx_hash_t</literal>: | 1238 <literal>ngx_hash_t</literal>: |
1200 <programlisting> | 1239 <programlisting> |
1201 ngx_hash_t foo_hash; | 1240 ngx_hash_t foo_hash; |
1202 ngx_hash_init_t hash; | 1241 ngx_hash_init_t hash; |
1203 | 1242 |
1204 hash.hash = &foo_hash; | 1243 hash.hash = &foo_hash; |
1207 hash.bucket_size = ngx_align(64, ngx_cacheline_size); | 1246 hash.bucket_size = ngx_align(64, ngx_cacheline_size); |
1208 hash.name = "foo_hash"; | 1247 hash.name = "foo_hash"; |
1209 hash.pool = cf->pool; | 1248 hash.pool = cf->pool; |
1210 hash.temp_pool = cf->temp_pool; | 1249 hash.temp_pool = cf->temp_pool; |
1211 </programlisting> | 1250 </programlisting> |
1212 The <literal>key</literal> is a pointer to a function that creates hash integer | 1251 The <literal>key</literal> is a pointer to a function that creates the hash |
1213 key from a string. | 1252 integer key from a string. |
1214 Two generic functions are provided: | 1253 There are two generic key-creation functions: |
1215 <literal>ngx_hash_key(data, len)</literal> and | 1254 <literal>ngx_hash_key(data, len)</literal> and |
1216 <literal>ngx_hash_key_lc(data, len)</literal>. | 1255 <literal>ngx_hash_key_lc(data, len)</literal>. |
1217 The latter converts a string to lowercase and thus requires the passed string to | 1256 The latter converts a string to all lowercase characters, so the passed string |
1218 be writable. | 1257 must be writeable. |
1219 If this is not true, <literal>NGX_HASH_READONLY_KEY</literal> flag | 1258 If that is not true, pass the <literal>NGX_HASH_READONLY_KEY</literal> flag |
1220 may be passed to the function, initializing array keys (see below). | 1259 to the function, initializing the key array (see below). |
1221 </para> | 1260 </para> |
1222 | 1261 |
1223 <para> | 1262 <para> |
1224 The hash keys are stored in <literal>ngx_hash_keys_arrays_t</literal> and | 1263 The hash keys are stored in <literal>ngx_hash_keys_arrays_t</literal> and |
1225 are initialized with <literal>ngx_hash_keys_array_init(arr, type)</literal>: | 1264 are initialized with <literal>ngx_hash_keys_array_init(arr, type)</literal>: |
1265 The second parameter (<literal>type</literal>) controls the amount of resources | |
1266 preallocated for the hash and can be either <literal>NGX_HASH_SMALL</literal> or | |
1267 <literal>NGX_HASH_LARGE</literal>. | |
1268 The latter is appropriate if you expect the hash to contain thousands of | |
1269 elements. | |
1270 | |
1226 <programlisting> | 1271 <programlisting> |
1227 ngx_hash_keys_arrays_t foo_keys; | 1272 ngx_hash_keys_arrays_t foo_keys; |
1228 | 1273 |
1229 foo_keys.pool = cf->pool; | 1274 foo_keys.pool = cf->pool; |
1230 foo_keys.temp_pool = cf->temp_pool; | 1275 foo_keys.temp_pool = cf->temp_pool; |
1231 | 1276 |
1232 ngx_hash_keys_array_init(&foo_keys, NGX_HASH_SMALL); | 1277 ngx_hash_keys_array_init(&foo_keys, NGX_HASH_SMALL); |
1233 </programlisting> | 1278 </programlisting> |
1234 The second parameter can be either <literal>NGX_HASH_SMALL</literal> or | 1279 </para> |
1235 <literal>NGX_HASH_LARGE</literal> and controls the amount of preallocated | 1280 |
1236 resources for the hash. | 1281 <para> |
1237 If you expect the hash to contain thousands elements, | 1282 To insert keys into a hash keys array, use the |
1238 use <literal>NGX_HASH_LARGE</literal>. | 1283 <literal>ngx_hash_add_key(keys_array, key, value, flags)</literal> function: |
1239 </para> | |
1240 | |
1241 <para> | |
1242 The <literal>ngx_hash_add_key(keys_array, key, value, flags)</literal> | |
1243 function is used to insert keys into hash keys array; | |
1244 <programlisting> | 1284 <programlisting> |
1245 ngx_str_t k1 = ngx_string("key1"); | 1285 ngx_str_t k1 = ngx_string("key1"); |
1246 ngx_str_t k2 = ngx_string("key2"); | 1286 ngx_str_t k2 = ngx_string("key2"); |
1247 | 1287 |
1248 ngx_hash_add_key(&foo_keys, &k1, &my_data_ptr_1, NGX_HASH_READONLY_KEY); | 1288 ngx_hash_add_key(&foo_keys, &k1, &my_data_ptr_1, NGX_HASH_READONLY_KEY); |
1249 ngx_hash_add_key(&foo_keys, &k2, &my_data_ptr_2, NGX_HASH_READONLY_KEY); | 1289 ngx_hash_add_key(&foo_keys, &k2, &my_data_ptr_2, NGX_HASH_READONLY_KEY); |
1250 </programlisting> | 1290 </programlisting> |
1251 </para> | 1291 </para> |
1252 | 1292 |
1253 <para> | 1293 <para> |
1254 Now, the hash table may be built using the call to | 1294 To build the hash table, call the |
1255 <literal>ngx_hash_init(hinit, key_names, nelts)</literal>: | 1295 <literal>ngx_hash_init(hinit, key_names, nelts)</literal> function: |
1256 | 1296 |
1257 <programlisting> | 1297 <programlisting> |
1258 ngx_hash_init(&hash, foo_keys.keys.elts, foo_keys.keys.nelts); | 1298 ngx_hash_init(&hash, foo_keys.keys.elts, foo_keys.keys.nelts); |
1259 </programlisting> | 1299 </programlisting> |
1260 | 1300 |
1261 This may fail, if <literal>max_size</literal> or <literal>bucket_size</literal> | 1301 The function fails if <literal>max_size</literal> or |
1262 parameters are not big enough. | 1302 <literal>bucket_size</literal> parameters are not big enough. |
1263 When the hash is built, <literal>ngx_hash_find(hash, key, name, len)</literal> | 1303 </para> |
1264 function may be used to look up elements: | 1304 |
1305 <para> | |
1306 When the hash is built, use the | |
1307 <literal>ngx_hash_find(hash, key, name, len)</literal> function to look up | |
1308 elements: | |
1265 <programlisting> | 1309 <programlisting> |
1266 my_data_t *data; | 1310 my_data_t *data; |
1267 ngx_uint_t key; | 1311 ngx_uint_t key; |
1268 | 1312 |
1269 key = ngx_hash_key(k1.data, k1.len); | 1313 key = ngx_hash_key(k1.data, k1.len); |
1277 </para> | 1321 </para> |
1278 | 1322 |
1279 <section name="Wildcard matching" id="wildcard_matching"> | 1323 <section name="Wildcard matching" id="wildcard_matching"> |
1280 | 1324 |
1281 <para> | 1325 <para> |
1282 To create a hash that works with wildcards, | 1326 To create a hash that works with wildcards, use the |
1283 <literal>ngx_hash_combined_t</literal> type is used. | 1327 <literal>ngx_hash_combined_t</literal> type. |
1284 It includes the hash type described above and has two additional keys arrays: | 1328 It includes the hash type described above and has two additional keys arrays: |
1285 <literal>dns_wc_head</literal> and <literal>dns_wc_tail</literal>. | 1329 <literal>dns_wc_head</literal> and <literal>dns_wc_tail</literal>. |
1286 The initialization of basic properties is done similarly to a usual hash: | 1330 The initialization of basic properties is similar to a regular hash: |
1287 <programlisting> | 1331 <programlisting> |
1288 ngx_hash_init_t hash | 1332 ngx_hash_init_t hash |
1289 ngx_hash_combined_t foo_hash; | 1333 ngx_hash_combined_t foo_hash; |
1290 | 1334 |
1291 hash.hash = &foo_hash.hash; | 1335 hash.hash = &foo_hash.hash; |
1300 /* k1 = ".example.org"; */ | 1344 /* k1 = ".example.org"; */ |
1301 /* k2 = "foo.*"; */ | 1345 /* k2 = "foo.*"; */ |
1302 ngx_hash_add_key(&foo_keys, &k1, &data1, NGX_HASH_WILDCARD_KEY); | 1346 ngx_hash_add_key(&foo_keys, &k1, &data1, NGX_HASH_WILDCARD_KEY); |
1303 ngx_hash_add_key(&foo_keys, &k2, &data2, NGX_HASH_WILDCARD_KEY); | 1347 ngx_hash_add_key(&foo_keys, &k2, &data2, NGX_HASH_WILDCARD_KEY); |
1304 </programlisting> | 1348 </programlisting> |
1305 The function recognizes wildcards and adds keys into corresponding arrays. | 1349 The function recognizes wildcards and adds keys into the corresponding arrays. |
1306 Please refer to the | 1350 Please refer to the |
1307 <link doc="../http/ngx_http_map_module.xml" id="map"/> module | 1351 <link doc="../http/ngx_http_map_module.xml" id="map"/> module |
1308 documentation for the description of the wildcard syntax and | 1352 documentation for the description of the wildcard syntax and the |
1309 matching algorithm. | 1353 matching algorithm. |
1310 </para> | 1354 </para> |
1311 | 1355 |
1312 <para> | 1356 <para> |
1313 Depending on the contents of added keys, you may need to initialize up to three | 1357 Depending on the contents of added keys, you may need to initialize up to three |
1314 keys arrays: one for exact matching (described above), and two for matching | 1358 key arrays: one for exact matching (described above), and two more to enable |
1315 starting from head or tail of a string: | 1359 matching starting from the head or tail of a string: |
1316 <programlisting> | 1360 <programlisting> |
1317 if (foo_keys.dns_wc_head.nelts) { | 1361 if (foo_keys.dns_wc_head.nelts) { |
1318 | 1362 |
1319 ngx_qsort(foo_keys.dns_wc_head.elts, | 1363 ngx_qsort(foo_keys.dns_wc_head.elts, |
1320 (size_t) foo_keys.dns_wc_head.nelts, | 1364 (size_t) foo_keys.dns_wc_head.nelts, |
1362 | 1406 |
1363 | 1407 |
1364 <section name="Heap" id="heap"> | 1408 <section name="Heap" id="heap"> |
1365 | 1409 |
1366 <para> | 1410 <para> |
1367 To allocate memory from system heap, the following functions are provided by | 1411 To allocate memory from system heap, use the following functions: |
1368 nginx: | |
1369 </para> | 1412 </para> |
1370 | 1413 |
1371 <para> | 1414 <para> |
1372 <list type="bullet"> | 1415 <list type="bullet"> |
1373 | 1416 |
1374 <listitem> | 1417 <listitem> |
1375 <literal>ngx_alloc(size, log)</literal> — allocate memory from system heap. | 1418 <literal>ngx_alloc(size, log)</literal> — Allocate memory from system heap. |
1376 This is a wrapper around <literal>malloc()</literal> with logging support. | 1419 This is a wrapper around <literal>malloc()</literal> with logging support. |
1377 Allocation error and debugging information is logged to <literal>log</literal> | 1420 Allocation error and debugging information is logged to <literal>log</literal>. |
1378 </listitem> | 1421 </listitem> |
1379 | 1422 |
1380 <listitem> | 1423 <listitem> |
1381 <literal>ngx_calloc(size, log)</literal> — same as | 1424 <literal>ngx_calloc(size, log)</literal> — Allocate memory from system heap |
1382 <literal>ngx_alloc()</literal>, but memory is filled with zeroes after | 1425 like <literal>ngx_alloc()</literal>, but fill memory with zeros after |
1383 allocation | 1426 allocation. |
1384 </listitem> | 1427 </listitem> |
1385 | 1428 |
1386 <listitem> | 1429 <listitem> |
1387 <literal>ngx_memalign(alignment, size, log)</literal> — allocate aligned memory | 1430 <literal>ngx_memalign(alignment, size, log)</literal> — Allocate aligned memory |
1388 from system heap. This is a wrapper around <literal>posix_memalign()</literal> | 1431 from system heap. |
1389 on those platforms which provide it. | 1432 This is a wrapper around <literal>posix_memalign()</literal> |
1433 on those platforms that provide that function. | |
1390 Otherwise implementation falls back to <literal>ngx_alloc()</literal> which | 1434 Otherwise implementation falls back to <literal>ngx_alloc()</literal> which |
1391 provides maximum alignment | 1435 provides maximum alignment. |
1392 </listitem> | 1436 </listitem> |
1393 | 1437 |
1394 <listitem> | 1438 <listitem> |
1395 <literal>ngx_free(p)</literal> — free allocated memory. | 1439 <literal>ngx_free(p)</literal> — Free allocated memory. |
1396 This is a wrapper around <literal>free()</literal> | 1440 This is a wrapper around <literal>free()</literal> |
1397 </listitem> | 1441 </listitem> |
1398 | 1442 |
1399 </list> | 1443 </list> |
1400 </para> | 1444 </para> |
1403 | 1447 |
1404 | 1448 |
1405 <section name="Pool" id="pool"> | 1449 <section name="Pool" id="pool"> |
1406 | 1450 |
1407 <para> | 1451 <para> |
1408 Most nginx allocations are done in pools. Memory allocated in an nginx pool is | 1452 Most nginx allocations are done in pools. |
1409 freed automatically when the pool in destroyed. This provides good | 1453 Memory allocated in an nginx pool is freed automatically when the pool is |
1410 allocation performance and makes memory control easy. | 1454 destroyed. |
1411 </para> | 1455 This provides good allocation performance and makes memory control easy. |
1412 | 1456 </para> |
1413 <para> | 1457 |
1414 A pool internally allocates objects in continuous blocks of memory. Once a | 1458 <para> |
1415 block is full, a new one is allocated and added to the pool memory | 1459 A pool internally allocates objects in continuous blocks of memory. |
1416 block list. When a large allocation is requested which does not fit into | 1460 Once a block is full, a new one is allocated and added to the pool memory |
1417 a block, such allocation is forwarded to the system allocator and the | 1461 block list. |
1462 When the requested allocation is too large to fit into a block, the request | |
1463 is forwarded to the system allocator and the | |
1418 returned pointer is stored in the pool for further deallocation. | 1464 returned pointer is stored in the pool for further deallocation. |
1419 </para> | 1465 </para> |
1420 | 1466 |
1421 <para> | 1467 <para> |
1422 Nginx pool has the type <literal>ngx_pool_t</literal>. | 1468 The type for nginx pools is <literal>ngx_pool_t</literal>. |
1423 The following operations are supported: | 1469 The following operations are supported: |
1424 </para> | 1470 </para> |
1425 | 1471 |
1426 <para> | 1472 <para> |
1427 <list type="bullet"> | 1473 <list type="bullet"> |
1428 | 1474 |
1429 <listitem> | 1475 <listitem> |
1430 <literal>ngx_create_pool(size, log)</literal> — create a pool with given | 1476 <literal>ngx_create_pool(size, log)</literal> — Create a pool with specified |
1431 block size. The pool object returned is allocated in the pool as well. | 1477 block size. |
1432 </listitem> | 1478 The pool object returned is allocated in the pool as well. |
1433 | 1479 </listitem> |
1434 <listitem> | 1480 |
1435 <literal>ngx_destroy_pool(pool)</literal> — free all pool memory, including | 1481 <listitem> |
1482 <literal>ngx_destroy_pool(pool)</literal> — Free all pool memory, including | |
1436 the pool object itself. | 1483 the pool object itself. |
1437 </listitem> | 1484 </listitem> |
1438 | 1485 |
1439 <listitem> | 1486 <listitem> |
1440 <literal>ngx_palloc(pool, size)</literal> — allocate aligned memory from pool | 1487 <literal>ngx_palloc(pool, size)</literal> — Allocate aligned memory from the |
1441 </listitem> | 1488 specified pool. |
1442 | 1489 </listitem> |
1443 <listitem> | 1490 |
1444 <literal>ngx_pcalloc(pool, size)</literal> — allocated aligned memory | 1491 <listitem> |
1445 from pool and fill it with zeroes | 1492 <literal>ngx_pcalloc(pool, size)</literal> — Allocate aligned memory |
1446 </listitem> | 1493 from the specified pool and fill it with zeroes. |
1447 | 1494 </listitem> |
1448 <listitem> | 1495 |
1449 <literal>ngx_pnalloc(pool, size)</literal> — allocate unaligned memory from pool. | 1496 <listitem> |
1450 Mostly used for allocating strings | 1497 <literal>ngx_pnalloc(pool, size)</literal> — Allocate unaligned memory from the |
1451 </listitem> | 1498 specified pool. |
1452 | 1499 Mostly used for allocating strings. |
1453 <listitem> | 1500 </listitem> |
1454 <literal>ngx_pfree(pool, p)</literal> — free memory, previously allocated | 1501 |
1455 in the pool. | 1502 <listitem> |
1456 Only allocations, forwarded to the system allocator, can be freed. | 1503 <literal>ngx_pfree(pool, p)</literal> — Free memory that was previously |
1504 allocated in the specified pool. | |
1505 Only allocations that result from requests forwarded to the system allocator | |
1506 can be freed. | |
1457 </listitem> | 1507 </listitem> |
1458 | 1508 |
1459 </list> | 1509 </list> |
1460 </para> | 1510 </para> |
1461 | 1511 |
1475 if (p == NULL) { /* error */ } | 1525 if (p == NULL) { /* error */ } |
1476 ngx_memcpy(p, "foo", 3); | 1526 ngx_memcpy(p, "foo", 3); |
1477 </programlisting> | 1527 </programlisting> |
1478 | 1528 |
1479 <para> | 1529 <para> |
1480 Since chain links <literal>ngx_chain_t</literal> are actively used in nginx, | 1530 Chain links (<literal>ngx_chain_t</literal>) are actively used in nginx, |
1481 nginx pool provides a way to reuse them. | 1531 so the nginx pool implementation provides a way to reuse them. |
1482 The <literal>chain</literal> field of <literal>ngx_pool_t</literal> keeps a | 1532 The <literal>chain</literal> field of <literal>ngx_pool_t</literal> keeps a |
1483 list of previously allocated links ready for reuse. For efficient allocation of | 1533 list of previously allocated links ready for reuse. |
1484 a chain link in a pool, the function | 1534 For efficient allocation of a chain link in a pool, use the |
1485 <literal>ngx_alloc_chain_link(pool)</literal> should be used. | 1535 <literal>ngx_alloc_chain_link(pool)</literal> function. |
1486 This function looks up a free chain link in the pool list and only if it's | 1536 This function looks up a free chain link in the pool list and allocates a new |
1487 empty allocates a new one. To free a link <literal>ngx_free_chain(pool, cl)</literal> | 1537 chain link if the pool list is empty. |
1488 should be called. | 1538 To free a link, call the <literal>ngx_free_chain(pool, cl)</literal> function. |
1489 </para> | 1539 </para> |
1490 | 1540 |
1491 <para> | 1541 <para> |
1492 Cleanup handlers can be registered in a pool. | 1542 Cleanup handlers can be registered in a pool. |
1493 Cleanup handler is a callback with an argument which is called when pool is | 1543 A cleanup handler is a callback with an argument which is called when pool is |
1494 destroyed. | 1544 destroyed. |
1495 Pool is usually tied with a specific nginx object (like HTTP request) and | 1545 A pool is usually tied to a specific nginx object (like an HTTP request) and is |
1496 destroyed in the end of that object’s lifetime, releasing the object itself. | 1546 destroyed when the object reaches the end of its lifetime. |
1497 Registering a pool cleanup is a convenient way to release resources, close file | 1547 Registering a pool cleanup is a convenient way to release resources, close |
1498 descriptors or make final adjustments to shared data, associated with the main | 1548 file descriptors or make final adjustments to the shared data associated with |
1499 object. | 1549 the main object. |
1500 </para> | 1550 </para> |
1501 | 1551 |
1502 <para> | 1552 <para> |
1503 A pool cleanup is registered by calling <literal>ngx_pool_cleanup_add(pool, | 1553 To register a pool cleanup, call |
1504 size)</literal> which returns <literal>ngx_pool_cleanup_t</literal> pointer to | 1554 <literal>ngx_pool_cleanup_add(pool, size)</literal>, which returns a |
1505 be filled by the caller. The <literal>size</literal> argument allows allocating | 1555 <literal>ngx_pool_cleanup_t</literal> pointer to |
1506 context for the cleanup handler. | 1556 be filled in by the caller. |
1557 Use the <literal>size</literal> argument to allocate context for the cleanup | |
1558 handler. | |
1507 </para> | 1559 </para> |
1508 | 1560 |
1509 | 1561 |
1510 <programlisting> | 1562 <programlisting> |
1511 ngx_pool_cleanup_t *cln; | 1563 ngx_pool_cleanup_t *cln; |
1532 | 1584 |
1533 <section name="Shared memory" id="shared_memory"> | 1585 <section name="Shared memory" id="shared_memory"> |
1534 | 1586 |
1535 <para> | 1587 <para> |
1536 Shared memory is used by nginx to share common data between processes. | 1588 Shared memory is used by nginx to share common data between processes. |
1537 Function <literal>ngx_shared_memory_add(cf, name, size, tag)</literal> adds a | 1589 The <literal>ngx_shared_memory_add(cf, name, size, tag)</literal> function adds |
1538 new shared memory entry <literal>ngx_shm_zone_t</literal> to the cycle. The | 1590 a new shared memory entry <literal>ngx_shm_zone_t</literal> to a cycle. |
1539 function receives <literal>name</literal> and <literal>size</literal> of the | 1591 The function receives the <literal>name</literal> and <literal>size</literal> |
1540 zone. | 1592 of the zone. |
1541 Each shared zone must have a unique name. | 1593 Each shared zone must have a unique name. |
1542 If a shared zone entry with the provided name exists, the old zone entry is | 1594 If a shared zone entry with the provided <literal>name</literal> and |
1543 reused, if its tag value matches too. | 1595 <literal>tag</literal> already exists, the existing zone entry is reused. |
1544 Mismatched tag is considered an error. | 1596 The function fails with an error if an existing entry with the same name has a |
1545 Usually, the address of the module structure is passed as tag, making it | 1597 different tag. |
1546 possible to reuse shared zones by name within one nginx module. | 1598 Usually, the address of the module structure is passed as |
1599 <literal>tag</literal>, making it possible to reuse shared zones by name within | |
1600 one nginx module. | |
1547 </para> | 1601 </para> |
1548 | 1602 |
1549 <para> | 1603 <para> |
1550 The shared memory entry structure <literal>ngx_shm_zone_t</literal> has the | 1604 The shared memory entry structure <literal>ngx_shm_zone_t</literal> has the |
1551 following fields: | 1605 following fields: |
1553 | 1607 |
1554 <para> | 1608 <para> |
1555 <list type="bullet"> | 1609 <list type="bullet"> |
1556 | 1610 |
1557 <listitem> | 1611 <listitem> |
1558 <literal>init</literal> — initialization callback, called after shared zone is | 1612 <literal>init</literal> — Initialization callback, called after the shared zone |
1559 mapped to actual memory | 1613 is mapped to actual memory |
1560 </listitem> | 1614 </listitem> |
1561 | 1615 |
1562 <listitem> | 1616 <listitem> |
1563 <literal>data</literal> — data context, used to pass arbitrary data to the | 1617 <literal>data</literal> — Data context, used to pass arbitrary data to the |
1564 <literal>init</literal> callback | 1618 <literal>init</literal> callback |
1565 </listitem> | 1619 </listitem> |
1566 | 1620 |
1567 <listitem> | 1621 <listitem> |
1568 <literal>noreuse</literal> — flag, disabling shared zone reuse from the | 1622 <literal>noreuse</literal> — Flag that disables reuse of a shared zone from the |
1569 old cycle | 1623 old cycle |
1570 </listitem> | 1624 </listitem> |
1571 | 1625 |
1572 <listitem> | 1626 <listitem> |
1573 <literal>tag</literal> — shared zone tag | 1627 <literal>tag</literal> — Shared zone tag |
1574 </listitem> | 1628 </listitem> |
1575 | 1629 |
1576 <listitem> | 1630 <listitem> |
1577 <literal>shm</literal> — platform-specific object of type | 1631 <literal>shm</literal> — Platform-specific object of type |
1578 <literal>ngx_shm_t</literal>, having at least the following fields: | 1632 <literal>ngx_shm_t</literal>, having at least the following fields: |
1579 <list type="bullet"> | 1633 <list type="bullet"> |
1580 | 1634 |
1581 <listitem> | 1635 <listitem> |
1582 <literal>addr</literal> — mapped shared memory address, initially NULL | 1636 <literal>addr</literal> — Mapped shared memory address, initially NULL |
1583 </listitem> | 1637 </listitem> |
1584 | 1638 |
1585 <listitem> | 1639 <listitem> |
1586 <literal>size</literal> — shared memory size | 1640 <literal>size</literal> — Shared memory size |
1587 </listitem> | 1641 </listitem> |
1588 | 1642 |
1589 <listitem> | 1643 <listitem> |
1590 <literal>name</literal> — shared memory name | 1644 <literal>name</literal> — Shared memory name |
1591 </listitem> | 1645 </listitem> |
1592 | 1646 |
1593 <listitem> | 1647 <listitem> |
1594 <literal>log</literal> — shared memory log | 1648 <literal>log</literal> — Shared memory log |
1595 </listitem> | 1649 </listitem> |
1596 | 1650 |
1597 <listitem> | 1651 <listitem> |
1598 <literal>exists</literal> — flag, showing that shared memory was inherited | 1652 <literal>exists</literal> — Flag that indicates shared memory was inherited |
1599 from the master process (Windows-specific) | 1653 from the master process (Windows-specific) |
1600 </listitem> | 1654 </listitem> |
1601 | 1655 |
1602 </list> | 1656 </list> |
1603 </listitem> | 1657 </listitem> |
1605 </list> | 1659 </list> |
1606 </para> | 1660 </para> |
1607 | 1661 |
1608 <para> | 1662 <para> |
1609 Shared zone entries are mapped to actual memory in | 1663 Shared zone entries are mapped to actual memory in |
1610 <literal>ngx_init_cycle()</literal> after configuration is parsed. | 1664 <literal>ngx_init_cycle()</literal> after the configuration is parsed. |
1611 On POSIX systems, <literal>mmap()</literal> syscall is used to create shared | 1665 On POSIX systems, the <literal>mmap()</literal> syscall is used to create the |
1612 anonymous mapping. | 1666 shared anonymous mapping. |
1613 On Windows, <literal>CreateFileMapping()/MapViewOfFileEx()</literal> pair is | 1667 On Windows, the <literal>CreateFileMapping()</literal>/ |
1614 used. | 1668 <literal>MapViewOfFileEx()</literal> pair is used. |
1615 </para> | 1669 </para> |
1616 | 1670 |
1617 <para> | 1671 <para> |
1618 For allocating in shared memory, nginx provides slab pool | 1672 For allocating in shared memory, nginx provides the slab pool |
1619 <literal>ngx_slab_pool_t</literal>. | 1673 <literal>ngx_slab_pool_t</literal> type. |
1620 In each nginx shared zone, a slab pool is automatically created for allocating | 1674 A slab pool for allocating memory is automatically created in each nginx shared |
1621 memory in that zone. | 1675 zone. |
1622 The pool is located in the beginning of the shared zone and can be accessed by | 1676 The pool is located in the beginning of the shared zone and can be accessed by |
1623 the expression <literal>(ngx_slab_pool_t *) shm_zone->shm.addr</literal>. | 1677 the expression <literal>(ngx_slab_pool_t *) shm_zone->shm.addr</literal>. |
1624 Allocation in shared zone is done by calling one of the functions | 1678 To allocate memory in a shared zone, call either |
1625 <literal>ngx_slab_alloc(pool, size)/ngx_slab_calloc(pool, size)</literal>. | 1679 <literal>ngx_slab_alloc(pool, size)</literal> or |
1626 Memory is freed by calling <literal>ngx_slab_free(pool, p)</literal>. | 1680 <literal>ngx_slab_calloc(pool, size)</literal>. |
1681 To free memory, call <literal>ngx_slab_free(pool, p)</literal>. | |
1627 </para> | 1682 </para> |
1628 | 1683 |
1629 <para> | 1684 <para> |
1630 Slab pool divides all shared zone into pages. | 1685 Slab pool divides all shared zone into pages. |
1631 Each page is used for allocating objects of the same size. | 1686 Each page is used for allocating objects of the same size. |
1632 Only the sizes which are powers of 2, and not less than 8, are considered. | 1687 The specified size must be a power of 2, and greater than the minimum size of |
1633 Other sizes are rounded up to one of these values. | 1688 8 bytes. |
1634 For each page, a bitmask is kept, showing which blocks within that page are in | 1689 Nonconforming values are rounded up. |
1635 use and which are free for allocation. | 1690 A bitmask for each page tracks which blocks are in use and which are free for |
1636 For sizes greater than half-page (usually, 2048 bytes), allocation is done by | 1691 allocation. |
1637 entire pages. | 1692 For sizes greater than a half page (which is usually 2048 bytes), allocation is |
1638 </para> | 1693 done an entire page at a time |
1639 | 1694 </para> |
1640 <para> | 1695 |
1641 To protect data in shared memory from concurrent access, mutex is available in | 1696 <para> |
1642 the <literal>mutex</literal> field of <literal>ngx_slab_pool_t</literal>. | 1697 To protect data in shared memory from concurrent access, use the mutex |
1643 The mutex is used by the slab pool while allocating and freeing memory. | 1698 available in the <literal>mutex</literal> field of |
1644 However, it can be used to protect any other user data structures, | 1699 <literal>ngx_slab_pool_t</literal>. |
1645 allocated in the shared zone. | 1700 A mutex is most commonly used by the slab pool while allocating and freeing |
1646 Locking is done by calling | 1701 memory, but it can be used to protect any other user data structures allocated |
1647 <literal>ngx_shmtx_lock(&shpool->mutex)</literal>, unlocking is done by | 1702 in the shared zone. |
1648 calling <literal>ngx_shmtx_unlock(&shpool->mutex)</literal>. | 1703 To lock or unlock a mutex, call |
1704 <literal>ngx_shmtx_lock(&shpool->mutex)</literal> or | |
1705 <literal>ngx_shmtx_unlock(&shpool->mutex)</literal> respectively. | |
1649 </para> | 1706 </para> |
1650 | 1707 |
1651 | 1708 |
1652 <programlisting> | 1709 <programlisting> |
1653 ngx_str_t name; | 1710 ngx_str_t name; |
1660 ctx = ngx_pcalloc(cf->pool, sizeof(ngx_foo_ctx_t)); | 1717 ctx = ngx_pcalloc(cf->pool, sizeof(ngx_foo_ctx_t)); |
1661 if (ctx == NULL) { | 1718 if (ctx == NULL) { |
1662 /* error */ | 1719 /* error */ |
1663 } | 1720 } |
1664 | 1721 |
1665 /* add an entry for 65k shared zone */ | 1722 /* add an entry for 64k shared zone */ |
1666 shm_zone = ngx_shared_memory_add(cf, &name, 65536, &ngx_foo_module); | 1723 shm_zone = ngx_shared_memory_add(cf, &name, 65536, &ngx_foo_module); |
1667 if (shm_zone == NULL) { | 1724 if (shm_zone == NULL) { |
1668 /* error */ | 1725 /* error */ |
1669 } | 1726 } |
1670 | 1727 |
1721 | 1778 |
1722 | 1779 |
1723 <section name="Logging" id="logging"> | 1780 <section name="Logging" id="logging"> |
1724 | 1781 |
1725 <para> | 1782 <para> |
1726 For logging nginx code uses <literal>ngx_log_t</literal> objects. | 1783 For logging nginx uses <literal>ngx_log_t</literal> objects. |
1727 Nginx logger provides support for several types of output: | 1784 The nginx logger supports several types of output: |
1728 | 1785 |
1729 <list type="bullet"> | 1786 <list type="bullet"> |
1730 | 1787 |
1731 <listitem> | 1788 <listitem> |
1732 stderr — logging to standard error output | 1789 stderr — Logging to standard error (stderr) |
1733 </listitem> | 1790 </listitem> |
1734 | 1791 |
1735 <listitem> | 1792 <listitem> |
1736 file — logging to file | 1793 file — Logging to a file |
1737 </listitem> | 1794 </listitem> |
1738 | 1795 |
1739 <listitem> | 1796 <listitem> |
1740 syslog — logging to syslog | 1797 syslog — Logging to syslog |
1741 </listitem> | 1798 </listitem> |
1742 | 1799 |
1743 <listitem> | 1800 <listitem> |
1744 memory — logging to internal memory storage for development purposes. | 1801 memory — Logging to internal memory storage for development purposes; the memory |
1745 The memory could be accessed later with debugger | 1802 can be accessed later with a debugger |
1746 </listitem> | 1803 </listitem> |
1747 | 1804 |
1748 </list> | 1805 </list> |
1749 </para> | 1806 </para> |
1750 | 1807 |
1751 <para> | 1808 <para> |
1752 A logger instance may actually be a chain of loggers, linked to each other with | 1809 A logger instance can be a chain of loggers, linked to each other with |
1753 the <literal>next</literal> field. | 1810 the <literal>next</literal> field. |
1754 Each message is written to all loggers in chain. | 1811 In this case, each message is written to all loggers in the chain. |
1755 </para> | 1812 </para> |
1756 | 1813 |
1757 <para> | 1814 <para> |
1758 Each logger has an error level which limits the messages written to that log. | 1815 For each logger, a severity level controls which messages are written to the |
1759 The following error levels are supported by nginx: | 1816 log (only events assigned that level or higher are logged). |
1817 The following severity levels are supported: | |
1760 </para> | 1818 </para> |
1761 | 1819 |
1762 <para> | 1820 <para> |
1763 <list type="bullet"> | 1821 <list type="bullet"> |
1764 | 1822 |
1796 | 1854 |
1797 </list> | 1855 </list> |
1798 </para> | 1856 </para> |
1799 | 1857 |
1800 <para> | 1858 <para> |
1801 For debug logging, debug mask is checked as well. The following debug masks | 1859 For debug logging, the debug mask is checked as well. |
1802 exist: | 1860 The debug masks are: |
1803 </para> | 1861 </para> |
1804 | 1862 |
1805 <para> | 1863 <para> |
1806 <list type="bullet"> | 1864 <list type="bullet"> |
1807 | 1865 |
1848 | 1906 |
1849 <para> | 1907 <para> |
1850 <list type="bullet"> | 1908 <list type="bullet"> |
1851 | 1909 |
1852 <listitem> | 1910 <listitem> |
1853 <literal>ngx_log_error(level, log, err, fmt, ...)</literal> — error logging | 1911 <literal>ngx_log_error(level, log, err, fmt, ...)</literal> — Error logging |
1854 </listitem> | 1912 </listitem> |
1855 | 1913 |
1856 <listitem> | 1914 <listitem> |
1857 <literal>ngx_log_debug0(level, log, err, fmt)</literal>, | 1915 <literal>ngx_log_debug0(level, log, err, fmt)</literal>, |
1858 <literal>ngx_log_debug1(level, log, err, fmt, arg1)</literal> etc — debug | 1916 <literal>ngx_log_debug1(level, log, err, fmt, arg1)</literal> etc — Debug |
1859 logging, up to 8 formatting arguments are supported | 1917 logging with up to eight supported formatting arguments |
1860 </listitem> | 1918 </listitem> |
1861 | 1919 |
1862 </list> | 1920 </list> |
1863 </para> | 1921 </para> |
1864 | 1922 |
1865 <para> | 1923 <para> |
1866 A log message is formatted in a buffer of size | 1924 A log message is formatted in a buffer of size |
1867 <literal>NGX_MAX_ERROR_STR</literal> (currently, 2048 bytes) on stack. | 1925 <literal>NGX_MAX_ERROR_STR</literal> (currently, 2048 bytes) on stack. |
1868 The message is prepended with error level, process PID, connection id (stored | 1926 The message is prepended with the severity level, process ID (PID), connection |
1869 in <literal>log->connection</literal>) and system error text. | 1927 ID (stored in <literal>log->connection</literal>), and the system error text. |
1870 For non-debug messages <literal>log->handler</literal> is called as well to | 1928 For non-debug messages <literal>log->handler</literal> is called as well to |
1871 prepend more specific information to the log message. | 1929 prepend more specific information to the log message. |
1872 HTTP module sets <literal>ngx_http_log_error()</literal> function as log | 1930 HTTP module sets <literal>ngx_http_log_error()</literal> function as log |
1873 handler to log client and server addresses, current action (stored in | 1931 handler to log client and server addresses, current action (stored in |
1874 <literal>log->action</literal>), client request line, server name etc. | 1932 <literal>log->action</literal>), client request line, server name etc. |
1875 </para> | 1933 </para> |
1876 | 1934 |
1877 <para> | |
1878 Example: | |
1879 </para> | |
1880 | |
1881 | |
1882 <programlisting> | 1935 <programlisting> |
1883 /* specify what is currently done */ | 1936 /* specify what is currently done */ |
1884 log->action = "sending mp4 to client”; | 1937 log->action = "sending mp4 to client”; |
1885 | 1938 |
1886 /* error and debug log */ | 1939 /* error and debug log */ |
1890 ngx_log_debug2(NGX_LOG_DEBUG_HTTP, mp4->file.log, 0, | 1943 ngx_log_debug2(NGX_LOG_DEBUG_HTTP, mp4->file.log, 0, |
1891 "mp4 start:%ui, length:%ui”, mp4->start, mp4->length); | 1944 "mp4 start:%ui, length:%ui”, mp4->start, mp4->length); |
1892 </programlisting> | 1945 </programlisting> |
1893 | 1946 |
1894 <para> | 1947 <para> |
1895 Logging result: | 1948 The example above results in log entries like these: |
1896 </para> | 1949 </para> |
1897 | 1950 |
1898 | 1951 |
1899 <programlisting> | 1952 <programlisting> |
1900 2016/09/16 22:08:52 [info] 17445#0: *1 client prematurely closed connection while | 1953 2016/09/16 22:08:52 [info] 17445#0: *1 client prematurely closed connection while |
1906 | 1959 |
1907 | 1960 |
1908 <section name="Cycle" id="cycle"> | 1961 <section name="Cycle" id="cycle"> |
1909 | 1962 |
1910 <para> | 1963 <para> |
1911 Cycle object keeps nginx runtime context, created from a specific | 1964 A cycle object stores the nginx runtime context created from a specific |
1912 configuration. | 1965 configuration. |
1913 The type of the cycle is <literal>ngx_cycle_t</literal>. | 1966 Its type is <literal>ngx_cycle_t</literal>. |
1914 Upon configuration reload a new cycle is created from the new version of nginx | 1967 The current cycle is referenced by the <literal>ngx_cycle</literal> global |
1915 configuration. | 1968 variable and inherited by nginx workers as they start. |
1916 The old cycle is usually deleted after a new one is successfully created. | 1969 Each time the nginx configuration is reloaded, a new cycle is created from the |
1917 Currently active cycle is held in the <literal>ngx_cycle</literal> global | 1970 new nginx configuration; the old cycle is usually deleted after the new one is |
1918 variable and is inherited by newly started nginx workers. | 1971 successfully created. |
1919 </para> | 1972 </para> |
1920 | 1973 |
1921 <para> | 1974 <para> |
1922 A cycle is created by the function <literal>ngx_init_cycle()</literal>. | 1975 A cycle is created by the <literal>ngx_init_cycle()</literal> function, which |
1923 The function receives the old cycle as the argument. | 1976 takes the previous cycle as its argument. |
1924 It's used to locate the configuration file and inherit as much resources as | 1977 The function locates the previous cycle's configuration file and inherits as |
1925 possible from the old cycle to keep nginx running smoothly. | 1978 many resources as possible from the previous cycle. |
1926 When nginx starts, a fake cycle called “init cycle” is created and is then | 1979 A placeholder cycle called "init cycle" is created as nginx start, then is |
1927 replaced by a normal cycle, built from configuration. | 1980 replaced by an actual cycle built from configuration. |
1928 </para> | 1981 </para> |
1929 | 1982 |
1930 <para> | 1983 <para> |
1931 Some members of the cycle: | 1984 Members of the cycle include: |
1932 </para> | 1985 </para> |
1933 | 1986 |
1934 <para> | 1987 <para> |
1935 <list type="bullet"> | 1988 <list type="bullet"> |
1936 | 1989 |
1937 <listitem> | 1990 <listitem> |
1938 <literal>pool</literal> — cycle pool. Created for each new cycle | 1991 <literal>pool</literal> — Cycle pool. |
1939 </listitem> | 1992 Created for each new cycle. |
1940 | 1993 </listitem> |
1941 <listitem> | 1994 |
1942 <literal>log</literal> — cycle log. Initially, this log is inherited from the | 1995 <listitem> |
1943 old cycle. | 1996 <literal>log</literal> — Cycle log. |
1944 After reading configuration, this member is set to point to | 1997 Initially inherited from the old cycle, it is set to point to |
1945 <literal>new_log</literal> | 1998 <literal>new_log</literal> after the configuration is read. |
1946 </listitem> | 1999 </listitem> |
1947 | 2000 |
1948 <listitem> | 2001 <listitem> |
1949 <literal>new_log</literal> — cycle log, created by the configuration. | 2002 <literal>new_log</literal> — Cycle log, created by the configuration. |
1950 It's affected by the root scope <literal>error_log</literal> directive | 2003 It's affected by the root-scope <literal>error_log</literal> directive. |
1951 </listitem> | 2004 </listitem> |
1952 | 2005 |
1953 <listitem> | 2006 <listitem> |
1954 <literal>connections</literal>, <literal>connection_n</literal> — | 2007 <literal>connections</literal>, <literal>connection_n</literal> — |
1955 array of connections of type <literal>ngx_connection_t</literal>, created by | 2008 Array of connections of type <literal>ngx_connection_t</literal>, created by |
1956 the event module while initializing each nginx worker. | 2009 the event module while initializing each nginx worker. |
1957 The number of connections <literal>connection_n</literal> is set by the | 2010 The <literal>worker_connections</literal> directive in the nginx configuration |
1958 <literal>worker_connections</literal> directive | 2011 sets the number of connections <literal>connection_n</literal>. |
1959 </listitem> | 2012 </listitem> |
1960 | 2013 |
1961 <listitem> | 2014 <listitem> |
1962 <literal>free_connections</literal>, | 2015 <literal>free_connections</literal>, |
1963 <literal>free_connection_n</literal> — list and number of currently available | 2016 <literal>free_connection_n</literal> — List and number of currently available |
1964 connections. | 2017 connections. |
1965 If no connections are available, nginx worker refuses to accept new clients or | 2018 If no connections are available, an nginx worker refuses to accept new clients |
1966 connect to upstream servers | 2019 or connect to upstream servers. |
1967 </listitem> | 2020 </listitem> |
1968 | 2021 |
1969 <listitem> | 2022 <listitem> |
1970 <literal>files</literal>, <literal>files_n</literal> — array for mapping file | 2023 <literal>files</literal>, <literal>files_n</literal> — Array for mapping file |
1971 descriptors to nginx connections. | 2024 descriptors to nginx connections. |
1972 This mapping is used by the event modules, having the | 2025 This mapping is used by the event modules, having the |
1973 <literal>NGX_USE_FD_EVENT</literal> flag (currently, it's poll and devpoll) | 2026 <literal>NGX_USE_FD_EVENT</literal> flag (currently, it's |
1974 </listitem> | 2027 <literal>poll</literal> and <literal>devpoll</literal>). |
1975 | 2028 </listitem> |
1976 <listitem> | 2029 |
1977 <literal>conf_ctx</literal> — array of core module configurations. | 2030 <listitem> |
1978 The configurations are created and filled while reading nginx configuration | 2031 <literal>conf_ctx</literal> — Array of core module configurations. |
1979 files | 2032 The configurations are created and filled during reading of nginx configuration |
1980 </listitem> | 2033 files. |
1981 | 2034 </listitem> |
1982 <listitem> | 2035 |
1983 <literal>modules</literal>, <literal>modules_n</literal> — array of modules | 2036 <listitem> |
1984 <literal>ngx_module_t</literal>, both static and dynamic, loaded by current | 2037 <literal>modules</literal>, <literal>modules_n</literal> — Array of modules |
1985 configuration | 2038 of type <literal>ngx_module_t</literal>, both static and dynamic, loaded by |
1986 </listitem> | 2039 the current configuration. |
1987 | 2040 </listitem> |
1988 <listitem> | 2041 |
1989 <literal>listening</literal> — array of listening objects | 2042 <listitem> |
2043 <literal>listening</literal> — Array of listening objects of type | |
1990 <literal>ngx_listening_t</literal>. | 2044 <literal>ngx_listening_t</literal>. |
1991 Listening objects are normally added by the the <literal>listen</literal> | 2045 Listening objects are normally added by the <literal>listen</literal> |
1992 directive of different modules which call the | 2046 directive of different modules which call the |
1993 <literal>ngx_create_listening()</literal> function. | 2047 <literal>ngx_create_listening()</literal> function. |
1994 Based on listening objects, listen sockets are created by nginx | 2048 Listen sockets are created based on the listening objects. |
1995 </listitem> | 2049 </listitem> |
1996 | 2050 |
1997 <listitem> | 2051 <listitem> |
1998 <literal>paths</literal> — array of paths <literal>ngx_path_t</literal>. | 2052 <literal>paths</literal> — Array of paths of type <literal>ngx_path_t</literal>. |
1999 Paths are added by calling the function <literal>ngx_add_path()</literal> from | 2053 Paths are added by calling the function <literal>ngx_add_path()</literal> from |
2000 modules which are going to operate on certain directories. | 2054 modules which are going to operate on certain directories. |
2001 These directories are created by nginx after reading configuration, if missing. | 2055 These directories are created by nginx after reading configuration, if missing. |
2002 Moreover, two handlers can be added for each path: | 2056 Moreover, two handlers can be added for each path: |
2003 | 2057 |
2004 <list type="bullet"> | 2058 <list type="bullet"> |
2005 | 2059 |
2006 <listitem> | 2060 <listitem> |
2007 path loader — executed only once in 60 seconds after starting or reloading | 2061 path loader — Executes only once in 60 seconds after starting or reloading |
2008 nginx. Normally, reads the directory and stores data in nginx shared | 2062 nginx. |
2009 memory. The handler is called from a dedicated nginx process “nginx | 2063 Normally, the loader reads the directory and stores data in nginx shared |
2010 cache loader” | 2064 memory. |
2011 </listitem> | 2065 The handler is called from the dedicated nginx process “nginx cache loader”. |
2012 | 2066 </listitem> |
2013 <listitem> | 2067 |
2014 path manager — executed periodically. Normally, removes old files from the | 2068 <listitem> |
2015 directory and reflects these changes in nginx memory. The handler is | 2069 path manager — Executes periodically. |
2016 called from a dedicated nginx process “nginx cache manager” | 2070 Normally, the manager removes old files from the directory and updates nginx |
2071 memory to reflect the changes. | |
2072 The handler is called from the dedicated “nginx cache manager” process. | |
2017 </listitem> | 2073 </listitem> |
2018 | 2074 |
2019 </list> | 2075 </list> |
2020 </listitem> | 2076 </listitem> |
2021 | 2077 |
2022 <listitem> | 2078 <listitem> |
2023 <literal>open_files</literal> — list of <literal>ngx_open_file_t</literal> | 2079 <literal>open_files</literal> — List of open file objects of type |
2024 objects. | 2080 <literal>ngx_open_file_t</literal>, which are created by calling the function |
2025 An open file object is created by calling the function | |
2026 <literal>ngx_conf_open_file()</literal>. | 2081 <literal>ngx_conf_open_file()</literal>. |
2027 After reading configuration nginx opens all files from the | 2082 Currently, nginx uses this kind of open files for logging. |
2028 <literal>open_files</literal> list and stores file descriptors in the | 2083 After reading the configuration, nginx opens all files in the |
2029 <literal>fd</literal> field of each open file object. | 2084 <literal>open_files</literal> list and stores each file descriptor in the |
2030 The files are opened in append mode and created if missing. | 2085 object's <literal>fd</literal> field. |
2031 The files from this list are reopened by nginx workers upon receiving the | 2086 The files are opened in append mode and are created if missing. |
2032 reopen signal (usually it's <literal>USR1</literal>). | 2087 The files in the list are reopened by nginx workers upon receiving the |
2033 In this case the <literal>fd</literal> fields are changed to new descriptors. | 2088 reopen signal (most often <literal>USR1</literal>). |
2034 The open files are currently used for logging | 2089 In this case the descriptor in the <literal>fd</literal> field is changed to a |
2035 </listitem> | 2090 new value. |
2036 | 2091 </listitem> |
2037 <listitem> | 2092 |
2038 <literal>shared_memory</literal> — list of shared memory zones, each added by | 2093 <listitem> |
2094 <literal>shared_memory</literal> — List of shared memory zones, each added by | |
2039 calling the <literal>ngx_shared_memory_add()</literal> function. | 2095 calling the <literal>ngx_shared_memory_add()</literal> function. |
2040 Shared zones are mapped to the same address range in all nginx processes and | 2096 Shared zones are mapped to the same address range in all nginx processes and |
2041 are used to share common data, for example HTTP cache in-memory tree | 2097 are used to share common data, for example the HTTP cache in-memory tree. |
2042 </listitem> | 2098 </listitem> |
2043 | 2099 |
2044 </list> | 2100 </list> |
2045 </para> | 2101 </para> |
2046 | 2102 |
2051 <para> | 2107 <para> |
2052 For input/output operations, nginx provides the buffer type | 2108 For input/output operations, nginx provides the buffer type |
2053 <literal>ngx_buf_t</literal>. | 2109 <literal>ngx_buf_t</literal>. |
2054 Normally, it's used to hold data to be written to a destination or read from a | 2110 Normally, it's used to hold data to be written to a destination or read from a |
2055 source. | 2111 source. |
2056 Buffer can reference data in memory and in file. | 2112 A buffer can reference data in memory or in a file and it's technically |
2057 Technically it's possible that a buffer references both at the same time. | 2113 possible for a buffer to reference both at the same time. |
2058 Memory for the buffer is allocated separately and is not related to the buffer | 2114 Memory for the buffer is allocated separately and is not related to the buffer |
2059 structure <literal>ngx_buf_t</literal>. | 2115 structure <literal>ngx_buf_t</literal>. |
2060 </para> | 2116 </para> |
2061 | 2117 |
2062 <para> | 2118 <para> |
2063 The structure <literal>ngx_buf_t</literal> has the following fields: | 2119 The <literal>ngx_buf_t</literal> structure has the following fields: |
2064 </para> | 2120 </para> |
2065 | 2121 |
2066 <para> | 2122 <para> |
2067 <list type="bullet"> | 2123 <list type="bullet"> |
2068 | 2124 |
2069 <listitem> | 2125 <listitem> |
2070 <literal>start</literal>, <literal>end</literal> — the boundaries of memory | 2126 <literal>start</literal>, <literal>end</literal> — The boundaries of the memory |
2071 block, allocated for the buffer | 2127 block allocated for the buffer. |
2072 </listitem> | 2128 </listitem> |
2073 | 2129 |
2074 <listitem> | 2130 <listitem> |
2075 <literal>pos</literal>, <literal>last</literal> — memory buffer boundaries, | 2131 <literal>pos</literal>, <literal>last</literal> — The boundaries of the memory |
2076 normally a subrange of <literal>start</literal> .. <literal>end</literal> | 2132 buffer; normally a subrange of <literal>start</literal> .. |
2077 </listitem> | 2133 <literal>end</literal>. |
2078 | 2134 </listitem> |
2079 <listitem> | 2135 |
2080 <literal>file_pos</literal>, <literal>file_last</literal> — file buffer | 2136 <listitem> |
2081 boundaries, these are offsets from the beginning of the file | 2137 <literal>file_pos</literal>, <literal>file_last</literal> — The boundaries of a |
2082 </listitem> | 2138 file buffer, expressed as offsets from the beginning of the file. |
2083 | 2139 </listitem> |
2084 <listitem> | 2140 |
2085 <literal>tag</literal> — unique value, used to distinguish buffers, created by | 2141 <listitem> |
2086 different nginx module, usually, for the purpose of buffer reuse | 2142 <literal>tag</literal> — Unique value used to distinguish buffers; created by |
2087 </listitem> | 2143 different nginx modules, usually for the purpose of buffer reuse. |
2088 | 2144 </listitem> |
2089 <listitem> | 2145 |
2090 <literal>file</literal> — file object | 2146 <listitem> |
2091 </listitem> | 2147 <literal>file</literal> — File object. |
2092 | 2148 </listitem> |
2093 <listitem> | 2149 |
2094 <literal>temporary</literal> — flag, meaning that the buffer references | 2150 <listitem> |
2095 writable memory | 2151 <literal>temporary</literal> — Flag indicating that the buffer references |
2096 </listitem> | 2152 writable memory. |
2097 | 2153 </listitem> |
2098 <listitem> | 2154 |
2099 <literal>memory</literal> — flag, meaning that the buffer references read-only | 2155 <listitem> |
2100 memory | 2156 <literal>memory</literal> — Flag indicating that the buffer references read-only |
2101 </listitem> | 2157 memory. |
2102 | 2158 </listitem> |
2103 <listitem> | 2159 |
2104 <literal>in_file</literal> — flag, meaning that current buffer references data | 2160 <listitem> |
2105 in a file | 2161 <literal>in_file</literal> — Flag indicating that the buffer references data |
2106 </listitem> | 2162 in a file. |
2107 | 2163 </listitem> |
2108 <listitem> | 2164 |
2109 <literal>flush</literal> — flag, meaning that all data prior to this buffer | 2165 <listitem> |
2110 should be flushed | 2166 <literal>flush</literal> — Flag indicating that all data prior to the buffer |
2111 </listitem> | 2167 need to be flushed. |
2112 | 2168 </listitem> |
2113 <listitem> | 2169 |
2114 <literal>recycled</literal> — flag, meaning that the buffer can be reused and | 2170 <listitem> |
2115 should be consumed as soon as possible | 2171 <literal>recycled</literal> — Flag indicating that the buffer can be reused and |
2116 </listitem> | 2172 needs to be consumed as soon as possible. |
2117 | 2173 </listitem> |
2118 <listitem> | 2174 |
2119 <literal>sync</literal> — flag, meaning that the buffer carries no data or | 2175 <listitem> |
2176 <literal>sync</literal> — Flag indicating that the buffer carries no data or | |
2120 special signal like <literal>flush</literal> or <literal>last_buf</literal>. | 2177 special signal like <literal>flush</literal> or <literal>last_buf</literal>. |
2121 Normally, such buffers are considered an error by nginx. This flags allows | 2178 By default nginx considers such buffers an error condition, but this flag tells |
2122 skipping the error checks | 2179 nginx to skip the error check. |
2123 </listitem> | 2180 </listitem> |
2124 | 2181 |
2125 <listitem> | 2182 <listitem> |
2126 <literal>last_buf</literal> — flag, meaning that current buffer is the last in | 2183 <literal>last_buf</literal> — Flag indicating that the buffer is the last in |
2127 output | 2184 output. |
2128 </listitem> | 2185 </listitem> |
2129 | 2186 |
2130 <listitem> | 2187 <listitem> |
2131 <literal>last_in_chain</literal> — flag, meaning that there's no more data | 2188 <literal>last_in_chain</literal> — Flag indicating that there are no more data |
2132 buffers in a (sub)request | 2189 buffers in a request or subrequest. |
2133 </listitem> | 2190 </listitem> |
2134 | 2191 |
2135 <listitem> | 2192 <listitem> |
2136 <literal>shadow</literal> — reference to another buffer, related to the current | 2193 <literal>shadow</literal> — Reference to another ("shadow") buffer related to |
2137 buffer. Usually current buffer uses data from the shadow buffer. Once current | 2194 the current buffer, usually in the sense that the buffer uses data from the |
2138 buffer is consumed, the shadow buffer should normally also be marked as | 2195 shadow. |
2139 consumed | 2196 When the buffer is consumed, the shadow buffer is normally also marked as |
2140 </listitem> | 2197 consumed. |
2141 | 2198 </listitem> |
2142 <listitem> | 2199 |
2143 <literal>last_shadow</literal> — flag, meaning that current buffer is the last | 2200 <listitem> |
2144 buffer, referencing a particular shadow buffer | 2201 <literal>last_shadow</literal> — Flag indicating that the buffer is the last |
2145 </listitem> | 2202 one that references a particular shadow buffer. |
2146 | 2203 </listitem> |
2147 <listitem> | 2204 |
2148 <literal>temp_file</literal> — flag, meaning that the buffer is in a temporary | 2205 <listitem> |
2149 file | 2206 <literal>temp_file</literal> — Flag indicating that the buffer is in a temporary |
2207 file. | |
2150 </listitem> | 2208 </listitem> |
2151 | 2209 |
2152 </list> | 2210 </list> |
2153 </para> | 2211 </para> |
2154 | 2212 |
2155 <para> | 2213 <para> |
2156 For input and output buffers are linked in chains. | 2214 For input and output operations buffers are linked in chains. |
2157 Chain is a sequence of chain links <literal>ngx_chain_t</literal>, defined as | 2215 A chain is a sequence of chain links of type <literal>ngx_chain_t</literal>, |
2158 follows: | 2216 defined as follows: |
2159 </para> | 2217 </para> |
2160 | 2218 |
2161 | 2219 |
2162 <programlisting> | 2220 <programlisting> |
2163 typedef struct ngx_chain_s ngx_chain_t; | 2221 typedef struct ngx_chain_s ngx_chain_t; |
2172 Each chain link keeps a reference to its buffer and a reference to the next | 2230 Each chain link keeps a reference to its buffer and a reference to the next |
2173 chain link. | 2231 chain link. |
2174 </para> | 2232 </para> |
2175 | 2233 |
2176 <para> | 2234 <para> |
2177 Example of using buffers and chains: | 2235 An example of using buffers and chains: |
2178 </para> | 2236 </para> |
2179 | 2237 |
2180 | 2238 |
2181 <programlisting> | 2239 <programlisting> |
2182 ngx_chain_t * | 2240 ngx_chain_t * |
2237 --> | 2295 --> |
2238 | 2296 |
2239 <section name="Connection" id="connection"> | 2297 <section name="Connection" id="connection"> |
2240 | 2298 |
2241 <para> | 2299 <para> |
2242 Connection type <literal>ngx_connection_t</literal> is a wrapper around a | 2300 The connection type <literal>ngx_connection_t</literal> is a wrapper around a |
2243 socket descriptor. Some of the structure fields are: | 2301 socket descriptor. |
2302 It includes the following fields: | |
2244 </para> | 2303 </para> |
2245 | 2304 |
2246 <para> | 2305 <para> |
2247 <list type="bullet"> | 2306 <list type="bullet"> |
2248 | 2307 |
2249 <listitem> | 2308 <listitem> |
2250 <literal>fd</literal> — socket descriptor | 2309 <literal>fd</literal> — Socket descriptor |
2251 </listitem> | 2310 </listitem> |
2252 | 2311 |
2253 <listitem> | 2312 <listitem> |
2254 <literal>data</literal> — arbitrary connection context. | 2313 <literal>data</literal> — Arbitrary connection context. |
2255 Normally, a pointer to a higher level object, built on top of the connection, | 2314 Normally, it is a pointer to a higher-level object built on top of the |
2256 like HTTP request or Stream session | 2315 connection, such as an HTTP request or a Stream session. |
2257 </listitem> | 2316 </listitem> |
2258 | 2317 |
2259 <listitem> | 2318 <listitem> |
2260 <literal>read</literal>, <literal>write</literal> — read and write events for | 2319 <literal>read</literal>, <literal>write</literal> — Read and write events for |
2261 the connection | 2320 the connection. |
2262 </listitem> | 2321 </listitem> |
2263 | 2322 |
2264 <listitem> | 2323 <listitem> |
2265 <literal>recv</literal>, <literal>send</literal>, | 2324 <literal>recv</literal>, <literal>send</literal>, |
2266 <literal>recv_chain</literal>, <literal>send_chain</literal> — I/O operations | 2325 <literal>recv_chain</literal>, <literal>send_chain</literal> — I/O operations |
2267 for the connection | 2326 for the connection. |
2268 </listitem> | 2327 </listitem> |
2269 | 2328 |
2270 <listitem> | 2329 <listitem> |
2271 <literal>pool</literal> — connection pool | 2330 <literal>pool</literal> — Connection pool. |
2272 </listitem> | 2331 </listitem> |
2273 | 2332 |
2274 <listitem> | 2333 <listitem> |
2275 <literal>log</literal> — connection log | 2334 <literal>log</literal> — Connection log. |
2276 </listitem> | 2335 </listitem> |
2277 | 2336 |
2278 <listitem> | 2337 <listitem> |
2279 <literal>sockaddr</literal>, <literal>socklen</literal>, | 2338 <literal>sockaddr</literal>, <literal>socklen</literal>, |
2280 <literal>addr_text</literal> — remote socket address in binary and text forms | 2339 <literal>addr_text</literal> — Remote socket address in binary and text forms. |
2281 </listitem> | 2340 </listitem> |
2282 | 2341 |
2283 <listitem> | 2342 <listitem> |
2284 <literal>local_sockaddr</literal>, <literal>local_socklen</literal> — local | 2343 <literal>local_sockaddr</literal>, <literal>local_socklen</literal> — Local |
2285 socket address in binary form. | 2344 socket address in binary form. |
2286 Initially, these fields are empty. | 2345 Initially, these fields are empty. |
2287 Function <literal>ngx_connection_local_sockaddr()</literal> should be used to | 2346 Use the <literal>ngx_connection_local_sockaddr()</literal> function to get the |
2288 get socket local address | 2347 local socket address. |
2289 </listitem> | 2348 </listitem> |
2290 | 2349 |
2291 <listitem> | 2350 <listitem> |
2292 <literal>proxy_protocol_addr</literal>, <literal>proxy_protocol_port</literal> | 2351 <literal>proxy_protocol_addr</literal>, <literal>proxy_protocol_port</literal> |
2293 - PROXY protocol client address and port, if PROXY protocol is enabled for the | 2352 - PROXY protocol client address and port, if the PROXY protocol is enabled for |
2294 connection | 2353 the connection. |
2295 </listitem> | 2354 </listitem> |
2296 | 2355 |
2297 <listitem> | 2356 <listitem> |
2298 <literal>ssl</literal> — nginx connection SSL context | 2357 <literal>ssl</literal> — SSL context for the connection. |
2299 </listitem> | 2358 </listitem> |
2300 | 2359 |
2301 <listitem> | 2360 <listitem> |
2302 <literal>reusable</literal> — flag, meaning, that the connection is at the | 2361 <literal>reusable</literal> — Flag indicating the connection is in a state that |
2303 state, when it can be reused | 2362 makes it eligible for reuse. |
2304 </listitem> | 2363 </listitem> |
2305 | 2364 |
2306 <listitem> | 2365 <listitem> |
2307 <literal>close</literal> — flag, meaning, that the connection is being reused | 2366 <literal>close</literal> — Flag indicating that the connection is being reused |
2308 and should be closed | 2367 and needs to be closed. |
2309 </listitem> | 2368 </listitem> |
2310 | 2369 |
2311 </list> | 2370 </list> |
2312 </para> | 2371 </para> |
2313 | 2372 |
2314 <para> | 2373 <para> |
2315 An nginx connection can transparently encapsulate SSL layer. | 2374 An nginx connection can transparently encapsulate the SSL layer. |
2316 In this case the connection <literal>ssl</literal> field holds a pointer to an | 2375 In this case the connection's <literal>ssl</literal> field holds a pointer to an |
2317 <literal>ngx_ssl_connection_t</literal> structure, keeping all SSL-related data | 2376 <literal>ngx_ssl_connection_t</literal> structure, keeping all SSL-related data |
2318 for the connection, including <literal>SSL_CTX</literal> and | 2377 for the connection, including <literal>SSL_CTX</literal> and |
2319 <literal>SSL</literal>. | 2378 <literal>SSL</literal>. |
2320 The handlers <literal>recv</literal>, <literal>send</literal>, | 2379 The <literal>recv</literal>, <literal>send</literal>, |
2321 <literal>recv_chain</literal>, <literal>send_chain</literal> are set as well to | 2380 <literal>recv_chain</literal>, and <literal>send_chain</literal> handlers are |
2322 SSL functions. | 2381 set to SSL-enabled functions as well. |
2323 </para> | 2382 </para> |
2324 | 2383 |
2325 <para> | 2384 <para> |
2326 The number of connections per nginx worker is limited by the | 2385 The <literal>worker_connections</literal> directive in the nginx configuration |
2327 <literal>worker_connections</literal> value. | 2386 limits the number of connections per nginx worker. |
2328 All connection structures are pre-created when a worker starts and stored in | 2387 All connection structures are precreated when a worker starts and stored in |
2329 the <literal>connections</literal> field of the cycle object. | 2388 the <literal>connections</literal> field of the cycle object. |
2330 To reach out for a connection structure, <literal>ngx_get_connection(s, | 2389 To retrieve a connection structure, use the |
2331 log)</literal> function is used. | 2390 <literal>ngx_get_connection(s, log)</literal> function. |
2332 The function receives a socket descriptor <literal>s</literal> which needs to | 2391 It takes as its <literal>s</literal> argument a socket descriptor, which needs |
2333 be wrapped in a connection structure. | 2392 to be wrapped in a connection structure. |
2334 </para> | 2393 </para> |
2335 | 2394 |
2336 <para> | 2395 <para> |
2337 Since the number of connections per worker is limited, nginx provides a | 2396 Because the number of connections per worker is limited, nginx provides a |
2338 way to grab connections which are currently in use. | 2397 way to grab connections that are currently in use. |
2339 To enable or disable reuse of a connection, function | 2398 To enable or disable reuse of a connection, call the |
2340 <literal>ngx_reusable_connection(c, reusable)</literal> is called. | 2399 <literal>ngx_reusable_connection(c, reusable)</literal> function. |
2341 Calling <literal>ngx_reusable_connection(c, 1)</literal> sets the | 2400 Calling <literal>ngx_reusable_connection(c, 1)</literal> sets the |
2342 <literal>reuse</literal> flag of the connection structure and inserts the | 2401 <literal>reuse</literal> flag in the connection structure and inserts the |
2343 connection in the <literal>reusable_connections_queue</literal> of the cycle. | 2402 connection into the <literal>reusable_connections_queue</literal> of the cycle. |
2344 Whenever <literal>ngx_get_connection()</literal> finds out there are no | 2403 Whenever <literal>ngx_get_connection()</literal> finds out there are no |
2345 available connections in the <literal>free_connections</literal> list of the | 2404 available connections in the cycle's <literal>free_connections</literal> list, |
2346 cycle, it calls <literal>ngx_drain_connections()</literal> to release a | 2405 it calls <literal>ngx_drain_connections()</literal> to release a |
2347 specific number of reusable connections. | 2406 specific number of reusable connections. |
2348 For each such connection, the <literal>close</literal> flag is set and its read | 2407 For each such connection, the <literal>close</literal> flag is set and its read |
2349 handler is called which is supposed to free the connection by calling | 2408 handler is called which is supposed to free the connection by calling |
2350 <literal>ngx_close_connection(c)</literal> and make it available for reuse. | 2409 <literal>ngx_close_connection(c)</literal> and make it available for reuse. |
2351 To exit the state when a connection can be reused | 2410 To exit the state when a connection can be reused |
2352 <literal>ngx_reusable_connection(c, 0)</literal> is called. | 2411 <literal>ngx_reusable_connection(c, 0)</literal> is called. |
2353 An example of reusable connections in nginx is HTTP client connections which | 2412 HTTP client connections are an example of reusable connections in nginx; they |
2354 are marked as reusable until some data is received from the client. | 2413 are marked as reusable until the first request byte is received from the client. |
2355 </para> | 2414 </para> |
2356 | 2415 |
2357 </section> | 2416 </section> |
2358 | 2417 |
2359 | 2418 |
2364 | 2423 |
2365 | 2424 |
2366 <section name="Event" id="event"> | 2425 <section name="Event" id="event"> |
2367 | 2426 |
2368 <para> | 2427 <para> |
2369 Event object <literal>ngx_event_t</literal> in nginx provides a way to be | 2428 Event object <literal>ngx_event_t</literal> in nginx provides a mechanism |
2370 notified of a specific event happening. | 2429 for notification that a specific event has occurred. |
2371 </para> | 2430 </para> |
2372 | 2431 |
2373 <para> | 2432 <para> |
2374 Some of the fields of the <literal>ngx_event_t</literal> are: | 2433 Fields in <literal>ngx_event_t</literal> include: |
2375 </para> | 2434 </para> |
2376 | 2435 |
2377 <para> | 2436 <para> |
2378 <list type="bullet"> | 2437 <list type="bullet"> |
2379 | 2438 |
2380 <listitem> | 2439 <listitem> |
2381 <literal>data</literal> — arbitrary event context, used in event handler, | 2440 <literal>data</literal> — Arbitrary event context used in event handlers, |
2382 usually, a pointer to a connection, tied with the event | 2441 usually as pointer to a connection related to the event. |
2383 </listitem> | 2442 </listitem> |
2384 | 2443 |
2385 <listitem> | 2444 <listitem> |
2386 <literal>handler</literal> — callback function to be invoked when the event | 2445 <literal>handler</literal> — Callback function to be invoked when the event |
2387 happens | 2446 happens. |
2388 </listitem> | 2447 </listitem> |
2389 | 2448 |
2390 <listitem> | 2449 <listitem> |
2391 <literal>write</literal> — flag, meaning that this is the write event. | 2450 <literal>write</literal> — Flag indicating a write event. |
2392 Used to distinguish between read and write events | 2451 Absence of the flag indicates a read event. |
2393 </listitem> | 2452 </listitem> |
2394 | 2453 |
2395 <listitem> | 2454 <listitem> |
2396 <literal>active</literal> — flag, meaning that the event is registered for | 2455 <literal>active</literal> — Flag indicating that the event is registered for |
2397 receiving I/O notifications, normally from notification mechanisms like epoll, | 2456 receiving I/O notifications, normally from notification mechanisms like |
2398 kqueue, poll | 2457 <literal>epoll</literal>, <literal>kqueue</literal>, <literal>poll</literal>. |
2399 </listitem> | 2458 </listitem> |
2400 | 2459 |
2401 <listitem> | 2460 <listitem> |
2402 <literal>ready</literal> — flag, meaning that the event has received an | 2461 <literal>ready</literal> — Flag indicating that the event has received an |
2403 I/O notification | 2462 I/O notification. |
2404 </listitem> | 2463 </listitem> |
2405 | 2464 |
2406 <listitem> | 2465 <listitem> |
2407 <literal>delayed</literal> — flag, meaning that I/O is delayed due to rate | 2466 <literal>delayed</literal> — Flag indicating that I/O is delayed due to rate |
2408 limiting | 2467 limiting. |
2409 </listitem> | 2468 </listitem> |
2410 | 2469 |
2411 <listitem> | 2470 <listitem> |
2412 <literal>timer</literal> — Red-Black tree node for inserting the event into | 2471 <literal>timer</literal> — Red-black tree node for inserting the event into |
2413 the timer tree | 2472 the timer tree. |
2414 </listitem> | 2473 </listitem> |
2415 | 2474 |
2416 <listitem> | 2475 <listitem> |
2417 <literal>timer_set</literal> — flag, meaning that the event timer is set, | 2476 <literal>timer_set</literal> — Flag indicating that the event timer is set and |
2418 but not yet expired | 2477 not yet expired. |
2419 </listitem> | 2478 </listitem> |
2420 | 2479 |
2421 <listitem> | 2480 <listitem> |
2422 <literal>timedout</literal> — flag, meaning that the event timer has expired | 2481 <literal>timedout</literal> — Flag indicating that the event timer has expired. |
2423 </listitem> | 2482 </listitem> |
2424 | 2483 |
2425 <listitem> | 2484 <listitem> |
2426 <literal>eof</literal> — read event flag, meaning that the eof has happened | 2485 <literal>eof</literal> — Flag indicating that EOF occurred while reading data. |
2427 while reading data | 2486 </listitem> |
2428 </listitem> | 2487 |
2429 | 2488 <listitem> |
2430 <listitem> | 2489 <literal>pending_eof</literal> — Flag indicating that EOF is pending on the |
2431 <literal>pending_eof</literal> — flag, meaning that the eof is pending on the | |
2432 socket, even though there may be some data available before it. | 2490 socket, even though there may be some data available before it. |
2433 The flag is delivered via <literal>EPOLLRDHUP</literal> epoll event or | 2491 The flag is delivered via the <literal>EPOLLRDHUP</literal> |
2434 <literal>EV_EOF</literal> kqueue flag | 2492 <literal>epoll</literal> event or |
2435 </listitem> | 2493 <literal>EV_EOF</literal> <literal>kqueue</literal> flag. |
2436 | 2494 </listitem> |
2437 <listitem> | 2495 |
2438 <literal>error</literal> — flag, meaning that an error has happened while | 2496 <listitem> |
2439 reading (for read event) or writing (for write event) | 2497 <literal>error</literal> — Flag indicating that an error occurred during |
2440 </listitem> | 2498 reading (for a read event) or writing (for a write event). |
2441 | 2499 </listitem> |
2442 <listitem> | 2500 |
2443 <literal>cancelable</literal> — timer event flag, meaning that the event | 2501 <listitem> |
2444 handler should be called while performing nginx worker graceful shutdown, event | 2502 <literal>cancelable</literal> — Timer event flag, used during graceful shutdown |
2445 though event timeout has not yet expired. The flag provides a way to finalize | 2503 of nginx workers, to signal that the event handler needs to be called even |
2446 certain activities, for example, flush log files | 2504 though the event timeout has not yet expired. |
2447 </listitem> | 2505 The flag provides a way to finalize certain activities, for example flush log |
2448 | 2506 files. |
2449 <listitem> | 2507 </listitem> |
2450 <literal>posted</literal> — flag, meaning that the event is posted to queue | 2508 |
2451 </listitem> | 2509 <listitem> |
2452 | 2510 <literal>posted</literal> — Flag indicating that the event is posted to a queue. |
2453 <listitem> | 2511 </listitem> |
2454 <literal>queue</literal> — queue node for posting the event to a queue | 2512 |
2513 <listitem> | |
2514 <literal>queue</literal> — Queue node for posting the event to a queue. | |
2455 </listitem> | 2515 </listitem> |
2456 | 2516 |
2457 </list> | 2517 </list> |
2458 </para> | 2518 </para> |
2459 | 2519 |
2461 | 2521 |
2462 | 2522 |
2463 <section name="I/O events" id="i_o_events"> | 2523 <section name="I/O events" id="i_o_events"> |
2464 | 2524 |
2465 <para> | 2525 <para> |
2466 Each connection, received with the | 2526 Each connection obtained by calling the <literal>ngx_get_connection()</literal> |
2467 <literal>ngx_get_connection()</literal> call, has two events attached to it: | 2527 function has two attached events, <literal>c->read</literal> and |
2468 <literal>c->read</literal> and <literal>c->write</literal>. | 2528 <literal>c->write</literal>, which are used for receiving notification that the |
2469 These events are used to receive notifications about the socket being ready for | 2529 socket is ready for reading or writing. |
2470 reading or writing. | |
2471 All such events operate in Edge-Triggered mode, meaning that they only trigger | 2530 All such events operate in Edge-Triggered mode, meaning that they only trigger |
2472 notifications when the state of the socket changes. | 2531 notifications when the state of the socket changes. |
2473 For example, doing a partial read on a socket will not make nginx deliver a | 2532 For example, doing a partial read on a socket does not make nginx deliver a |
2474 repeated read notification until more data arrive in the socket. | 2533 repeated read notification until more data arrives on the socket. |
2475 Even when the underlying I/O notification mechanism is essentially | 2534 Even when the underlying I/O notification mechanism is essentially |
2476 Level-Triggered (poll, select etc), nginx will turn the notifications into | 2535 Level-Triggered (<literal>poll</literal>, <literal>select</literal> etc), nginx |
2477 Edge-Triggered. | 2536 converts the notifications to Edge-Triggered. |
2478 To make nginx event notifications consistent across all notifications systems | 2537 To make nginx event notifications consistent across all notifications systems |
2479 on different platforms, it's required, that the functions | 2538 on different platforms, the functions |
2480 <literal>ngx_handle_read_event(rev, flags)</literal> and | 2539 <literal>ngx_handle_read_event(rev, flags)</literal> and |
2481 <literal>ngx_handle_write_event(wev, lowat)</literal> are called after handling | 2540 <literal>ngx_handle_write_event(wev, lowat)</literal> must be called after |
2482 an I/O socket notification or calling any I/O functions on that socket. | 2541 handling an I/O socket notification or calling any I/O functions on that socket. |
2483 Normally, these functions are called once in the end of each read or write | 2542 Normally, the functions are called once at the end of each read or write |
2484 event handler. | 2543 event handler. |
2485 </para> | 2544 </para> |
2486 | 2545 |
2487 </section> | 2546 </section> |
2488 | 2547 |
2489 | 2548 |
2490 <section name="Timer events" id="timer_events"> | 2549 <section name="Timer events" id="timer_events"> |
2491 | 2550 |
2492 <para> | 2551 <para> |
2493 An event can be set to notify a timeout expiration. | 2552 An event can be set to send a notification when a timeout expires. |
2494 The function <literal>ngx_add_timer(ev, timer)</literal> sets a timeout for an | 2553 The function <literal>ngx_add_timer(ev, timer)</literal> sets a timeout for an |
2495 event, <literal>ngx_del_timer(ev)</literal> deletes a previously set timeout. | 2554 event, <literal>ngx_del_timer(ev)</literal> deletes a previously set timeout. |
2496 Timeouts currently set for all existing events, are kept in a global timeout | 2555 The global timeout red-black tree <literal>ngx_event_timer_rbtree</literal> |
2497 Red-Black tree <literal>ngx_event_timer_rbtree</literal>. | 2556 stores all timeouts currently set. |
2498 The key in that tree has the type <literal>ngx_msec_t</literal> and is the time | 2557 The key in the tree is of type <literal>ngx_msec_t</literal> and is the time |
2499 in milliseconds since the beginning of January 1, 1970 (modulus | 2558 when the event expires, expressed in milliseconds since the midnight on of |
2500 <literal>ngx_msec_t</literal> max value) at which the event should expire. | 2559 January 1, 1970 modulus <literal>ngx_msec_t</literal> max value. |
2501 The tree structure provides fast inserting and deleting operations, as well as | 2560 The tree structure enables fast insertion and deletion operations, as well as |
2502 accessing the nearest timeouts. | 2561 access to the nearest timeouts, which nginx uses to find out how long to wait |
2503 The latter is used by nginx to find out for how long to wait for I/O events | 2562 for I/O events and for expiring timeout events. |
2504 and for expiring timeout events afterwards. | |
2505 </para> | 2563 </para> |
2506 | 2564 |
2507 </section> | 2565 </section> |
2508 | 2566 |
2509 | 2567 |
2513 An event can be posted which means that its handler will be called at some | 2571 An event can be posted which means that its handler will be called at some |
2514 point later within the current event loop iteration. | 2572 point later within the current event loop iteration. |
2515 Posting events is a good practice for simplifying code and escaping stack | 2573 Posting events is a good practice for simplifying code and escaping stack |
2516 overflows. | 2574 overflows. |
2517 Posted events are held in a post queue. | 2575 Posted events are held in a post queue. |
2518 The macro <literal>ngx_post_event(ev, q)</literal> posts the event | 2576 The <literal>ngx_post_event(ev, q)</literal> mscro posts the event |
2519 <literal>ev</literal> to the post queue <literal>q</literal>. | 2577 <literal>ev</literal> to the post queue <literal>q</literal>. |
2520 Macro <literal>ngx_delete_posted_event(ev)</literal> deletes the event | 2578 The <literal>ngx_delete_posted_event(ev)</literal> macro deletes the event |
2521 <literal>ev</literal> from whatever queue it's currently posted. | 2579 <literal>ev</literal> from the queue it's currently posted in. |
2522 Normally, events are posted to the <literal>ngx_posted_events</literal> queue. | 2580 Normally, events are posted to the <literal>ngx_posted_events</literal> queue, |
2523 This queue is processed late in the event loop — after all I/O and timer | 2581 which is processed late in the event loop — after all I/O and timer |
2524 events are already handled. | 2582 events are already handled. |
2525 The function <literal>ngx_event_process_posted()</literal> is called to process | 2583 The function <literal>ngx_event_process_posted()</literal> is called to process |
2526 an event queue. | 2584 an event queue. |
2527 This function calls event handlers until the queue is not empty. This means | 2585 It calls event handlers until the queue is not empty. |
2528 that a posted event handler can post more events to be processed within the | 2586 This means that a posted event handler can post more events to be processed |
2529 current event loop iteration. | 2587 within the current event loop iteration. |
2530 </para> | 2588 </para> |
2531 | 2589 |
2532 <para> | 2590 <para> |
2533 Example: | 2591 An example: |
2534 </para> | 2592 </para> |
2535 | 2593 |
2536 | 2594 |
2537 <programlisting> | 2595 <programlisting> |
2538 void | 2596 void |
2581 | 2639 |
2582 | 2640 |
2583 <section name="Event loop" id="event_loop"> | 2641 <section name="Event loop" id="event_loop"> |
2584 | 2642 |
2585 <para> | 2643 <para> |
2586 All nginx processes which do I/O, have an event loop. | 2644 Except for the nginx master process, all nginx processes do I/O and so have an |
2587 The only type of process which does not have I/O, is nginx master process which | 2645 event loop. |
2588 spends most of its time in <literal>sigsuspend()</literal> call waiting for | 2646 (The nginx master process instead spends most of its time in the |
2589 signals to arrive. | 2647 <literal>sigsuspend()</literal> call waiting for signals to arrive.) |
2590 Event loop is implemented in <literal>ngx_process_events_and_timers()</literal> | 2648 The nginx event loop is implemented in the |
2591 function. | 2649 <literal>ngx_process_events_and_timers()</literal> function, which is called |
2592 This function is called repeatedly until the process exits. | 2650 repeatedly until the process exits. |
2593 It has the following stages: | 2651 </para> |
2594 </para> | 2652 |
2595 | 2653 <para> |
2596 <para> | 2654 The event loop has the following stages: |
2655 | |
2597 <list type="bullet"> | 2656 <list type="bullet"> |
2598 | 2657 |
2599 <listitem> | 2658 <listitem> |
2600 find nearest timeout by calling <literal>ngx_event_find_timer()</literal>. | 2659 Find the timeout that is closest to expiring, by calling |
2601 This function finds the leftmost timer tree node and returns the number of | 2660 <literal>ngx_event_find_timer()</literal>. |
2602 milliseconds until that node expires | 2661 This function finds the leftmost node in the timer tree and returns the |
2603 </listitem> | 2662 number of milliseconds until the node expires. |
2604 | 2663 </listitem> |
2605 <listitem> | 2664 |
2606 process I/O events by calling a handler, specific to event notification | 2665 <listitem> |
2666 Process I/O events by calling a handler, specific to the event notification | |
2607 mechanism, chosen by nginx configuration. | 2667 mechanism, chosen by nginx configuration. |
2608 This handler waits for at least one I/O event to happen, but no longer, than | 2668 This handler waits for at least one I/O event to happen, but only until the next |
2609 the nearest timeout. | 2669 timeout expires. |
2610 For each read or write event which has happened, the <literal>ready</literal> | 2670 When a read or write event occurs, the <literal>ready</literal> |
2611 flag is set and its handler is called. | 2671 flag is set and the event's handler is called. |
2612 For Linux, normally, the <literal>ngx_epoll_process_events()</literal> handler | 2672 For Linux, the <literal>ngx_epoll_process_events()</literal> handler |
2613 is used which calls <literal>epoll_wait()</literal> to wait for I/O events | 2673 is normally used, which calls <literal>epoll_wait()</literal> to wait for I/O |
2614 </listitem> | 2674 events. |
2615 | 2675 </listitem> |
2616 <listitem> | 2676 |
2617 expire timers by calling <literal>ngx_event_expire_timers()</literal>. | 2677 <listitem> |
2618 The timer tree is iterated from the leftmost element to the right until a not | 2678 Expire timers by calling <literal>ngx_event_expire_timers()</literal>. |
2619 yet expired timeout is found. | 2679 The timer tree is iterated from the leftmost element to the right until an |
2680 unexpired timeout is found. | |
2620 For each expired node the <literal>timedout</literal> event flag is set, | 2681 For each expired node the <literal>timedout</literal> event flag is set, |
2621 <literal>timer_set</literal> flag is reset, and the event handler is called | 2682 the <literal>timer_set</literal> flag is reset, and the event handler is called |
2622 </listitem> | 2683 </listitem> |
2623 | 2684 |
2624 <listitem> | 2685 <listitem> |
2625 process posted events by calling <literal>ngx_event_process_posted()</literal>. | 2686 Process posted events by calling <literal>ngx_event_process_posted()</literal>. |
2626 The function repeatedly removes the first element from the posted events | 2687 The function repeatedly removes the first element from the posted events |
2627 queue and calls its handler until the queue gets empty | 2688 queue and calls the element's handler, until the queue is empty. |
2628 </listitem> | 2689 </listitem> |
2629 | 2690 |
2630 </list> | 2691 </list> |
2631 </para> | 2692 </para> |
2632 | 2693 |
4056 It stores global settings for a module | 4117 It stores global settings for a module |
4057 </listitem> | 4118 </listitem> |
4058 | 4119 |
4059 <listitem> | 4120 <listitem> |
4060 Server configuration. | 4121 Server configuration. |
4061 This configuraion applies to a single nginx server{}. | 4122 This configuration applies to a single nginx server{}. |
4062 It stores server-specific settings for a module | 4123 It stores server-specific settings for a module |
4063 </listitem> | 4124 </listitem> |
4064 | 4125 |
4065 <listitem> | 4126 <listitem> |
4066 Location configuration. | 4127 Location configuration. |
4067 This configuraion applies to a single location{}, if{} or limit_except() block. | 4128 This configuration applies to a single location{}, if{} or limit_except() block. |
4068 This configuration stores settings specific to a location | 4129 This configuration stores settings specific to a location |
4069 </listitem> | 4130 </listitem> |
4070 | 4131 |
4071 </list> | 4132 </list> |
4072 | 4133 |
4297 </listitem> | 4358 </listitem> |
4298 | 4359 |
4299 <listitem> | 4360 <listitem> |
4300 <literal>NGX_HTTP_REWRITE_PHASE</literal> — same as | 4361 <literal>NGX_HTTP_REWRITE_PHASE</literal> — same as |
4301 <literal>NGX_HTTP_SERVER_REWRITE_PHASE</literal>, but for a new location, | 4362 <literal>NGX_HTTP_SERVER_REWRITE_PHASE</literal>, but for a new location, |
4302 chosen at the prevous phase | 4363 chosen at the previous phase |
4303 </listitem> | 4364 </listitem> |
4304 | 4365 |
4305 <listitem> | 4366 <listitem> |
4306 <literal>NGX_HTTP_POST_REWRITE_PHASE</literal> — a special phase, used to | 4367 <literal>NGX_HTTP_POST_REWRITE_PHASE</literal> — a special phase, used to |
4307 redirect the request to a new location, if the URI was changed during rewrite. | 4368 redirect the request to a new location, if the URI was changed during rewrite. |
4609 is used. | 4670 is used. |
4610 It takes configuration (where variable is registered), variable name and | 4671 It takes configuration (where variable is registered), variable name and |
4611 flags that control its behaviour: | 4672 flags that control its behaviour: |
4612 | 4673 |
4613 <list type="bullet"> | 4674 <list type="bullet"> |
4614 <listitem><literal>NGX_HTTP_VAR_CHANGEABLE</literal> — allows redefining | 4675 <listitem><literal>NGX_HTTP_VAR_CHANGEABLE</literal> — allows redefining |
4615 the variable; If another module will define a variable with such name, | 4676 the variable; If another module will define a variable with such name, |
4616 no conflict will happen. | 4677 no conflict will happen. |
4617 For example, this allows user to override variables using the | 4678 For example, this allows user to override variables using the |
4618 <link doc="../http/ngx_http_rewrite_module.xml" id="set"/> directive. | 4679 <link doc="../http/ngx_http_rewrite_module.xml" id="set"/> directive. |
4619 </listitem> | 4680 </listitem> |
4620 | 4681 |
4621 <listitem><literal>NGX_HTTP_VAR_NOCACHEABLE</literal> — disables caching, | 4682 <listitem><literal>NGX_HTTP_VAR_NOCACHEABLE</literal> — disables caching, |
4622 is useful for such variables as <literal>$time_local</literal> | 4683 is useful for such variables as <literal>$time_local</literal> |
4623 </listitem> | 4684 </listitem> |
4624 | 4685 |
4625 <listitem><literal>NGX_HTTP_VAR_NOHASH</literal> — indicates that | 4686 <listitem><literal>NGX_HTTP_VAR_NOHASH</literal> — indicates that |
4626 this variable is only accessible by index, not by name. | 4687 this variable is only accessible by index, not by name. |
4627 This is a small optimization which may be used when it is known that the | 4688 This is a small optimization which may be used when it is known that the |
4628 variable is not needed in modules like SSI or Perl. | 4689 variable is not needed in modules like SSI or Perl. |
4629 </listitem> | 4690 </listitem> |
4630 | 4691 |
4631 <listitem><literal>NGX_HTTP_VAR_PREFIX</literal> — the name of this | 4692 <listitem><literal>NGX_HTTP_VAR_PREFIX</literal> — the name of this |
4632 variable is a prefix. | 4693 variable is a prefix. |
4633 A handler must implement additional logic to obtain value of specific | 4694 A handler must implement additional logic to obtain value of specific |
4634 variable. | 4695 variable. |
4635 For example, all “<literal>arg_</literal>” variables are processed by the | 4696 For example, all “<literal>arg_</literal>” variables are processed by the |
4636 same handler which performs lookup in request arguments and returns value | 4697 same handler which performs lookup in request arguments and returns value |
4936 </programlisting> | 4997 </programlisting> |
4937 | 4998 |
4938 <para> | 4999 <para> |
4939 The function <literal>ngx_http_named_location(r, name)</literal> redirects | 5000 The function <literal>ngx_http_named_location(r, name)</literal> redirects |
4940 a request to a named location. The name of the location is passed as the | 5001 a request to a named location. The name of the location is passed as the |
4941 argument. The location is looked up among all named locations of the current | 5002 argument. |
5003 The location is looked up among all named locations of the current | |
4942 server, after which the requests switches to the | 5004 server, after which the requests switches to the |
4943 <literal>NGX_HTTP_REWRITE_PHASE</literal> phase. | 5005 <literal>NGX_HTTP_REWRITE_PHASE</literal> phase. |
4944 </para> | 5006 </para> |
4945 | 5007 |
4946 <para> | 5008 <para> |
4961 | 5023 |
4962 <para> | 5024 <para> |
4963 Both functions <literal>ngx_http_internal_redirect(r, uri, args)</literal> | 5025 Both functions <literal>ngx_http_internal_redirect(r, uri, args)</literal> |
4964 and <literal>ngx_http_named_location(r, name)</literal> may be called when | 5026 and <literal>ngx_http_named_location(r, name)</literal> may be called when |
4965 a request already has some contexts saved in its <literal>ctx</literal> field | 5027 a request already has some contexts saved in its <literal>ctx</literal> field |
4966 by nginx modules. These contexts could become inconsistent with the new | 5028 by nginx modules. |
4967 location configuration. To prevent inconsistency, all request contexts are | 5029 These contexts could become inconsistent with the new |
5030 location configuration. | |
5031 To prevent inconsistency, all request contexts are | |
4968 erased by both redirect functions. | 5032 erased by both redirect functions. |
4969 </para> | 5033 </para> |
4970 | 5034 |
4971 <para> | 5035 <para> |
4972 Redirected and rewritten requests become internal and may access the | 5036 Redirected and rewritten requests become internal and may access the |
4973 <link doc="../http/ngx_http_core_module.xml" id="internal">internal</link> | 5037 <link doc="../http/ngx_http_core_module.xml" id="internal">internal</link> |
4974 locations. Internal requests have the <literal>internal</literal> flag set. | 5038 locations. |
5039 Internal requests have the <literal>internal</literal> flag set. | |
4975 </para> | 5040 </para> |
4976 | 5041 |
4977 </section> | 5042 </section> |
4978 | 5043 |
4979 | 5044 |