… | |
… | |
275 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
275 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
276 | |
276 | |
277 | If you don't know what event loop to use, use the one returned from this |
277 | If you don't know what event loop to use, use the one returned from this |
278 | function. |
278 | function. |
279 | |
279 | |
|
|
280 | Note that this function is I<not> thread-safe, so if you want to use it |
|
|
281 | from multiple threads, you have to lock (note also that this is unlikely, |
|
|
282 | as loops cannot bes hared easily between threads anyway). |
|
|
283 | |
280 | The default loop is the only loop that can handle C<ev_signal> and |
284 | The default loop is the only loop that can handle C<ev_signal> and |
281 | C<ev_child> watchers, and to do this, it always registers a handler |
285 | C<ev_child> watchers, and to do this, it always registers a handler |
282 | for C<SIGCHLD>. If this is a problem for your app you can either |
286 | for C<SIGCHLD>. If this is a problem for your app you can either |
283 | create a dynamic loop with C<ev_loop_new> that doesn't do that, or you |
287 | create a dynamic loop with C<ev_loop_new> that doesn't do that, or you |
284 | can simply overwrite the C<SIGCHLD> signal handler I<after> calling |
288 | can simply overwrite the C<SIGCHLD> signal handler I<after> calling |
… | |
… | |
465 | |
469 | |
466 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
470 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
467 | always distinct from the default loop. Unlike the default loop, it cannot |
471 | always distinct from the default loop. Unlike the default loop, it cannot |
468 | handle signal and child watchers, and attempts to do so will be greeted by |
472 | handle signal and child watchers, and attempts to do so will be greeted by |
469 | undefined behaviour (or a failed assertion if assertions are enabled). |
473 | undefined behaviour (or a failed assertion if assertions are enabled). |
|
|
474 | |
|
|
475 | Note that this function I<is> thread-safe, and the recommended way to use |
|
|
476 | libev with threads is indeed to create one loop per thread, and using the |
|
|
477 | default loop in the "main" or "initial" thread. |
470 | |
478 | |
471 | Example: Try to create a event loop that uses epoll and nothing else. |
479 | Example: Try to create a event loop that uses epoll and nothing else. |
472 | |
480 | |
473 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
481 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
474 | if (!epoller) |
482 | if (!epoller) |
… | |
… | |
1085 | To support fork in your programs, you either have to call |
1093 | To support fork in your programs, you either have to call |
1086 | C<ev_default_fork ()> or C<ev_loop_fork ()> after a fork in the child, |
1094 | C<ev_default_fork ()> or C<ev_loop_fork ()> after a fork in the child, |
1087 | enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or |
1095 | enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or |
1088 | C<EVBACKEND_POLL>. |
1096 | C<EVBACKEND_POLL>. |
1089 | |
1097 | |
|
|
1098 | =head3 The special problem of SIGPIPE |
|
|
1099 | |
|
|
1100 | While not really specific to libev, it is easy to forget about SIGPIPE: |
|
|
1101 | when reading from a pipe whose other end has been closed, your program |
|
|
1102 | gets send a SIGPIPE, which, by default, aborts your program. For most |
|
|
1103 | programs this is sensible behaviour, for daemons, this is usually |
|
|
1104 | undesirable. |
|
|
1105 | |
|
|
1106 | So when you encounter spurious, unexplained daemon exits, make sure you |
|
|
1107 | ignore SIGPIPE (and maybe make sure you log the exit status of your daemon |
|
|
1108 | somewhere, as that would have given you a big clue). |
|
|
1109 | |
1090 | |
1110 | |
1091 | =head3 Watcher-Specific Functions |
1111 | =head3 Watcher-Specific Functions |
1092 | |
1112 | |
1093 | =over 4 |
1113 | =over 4 |
1094 | |
1114 | |
… | |
… | |
1599 | reader). Inotify will be used to give hints only and should not change the |
1619 | reader). Inotify will be used to give hints only and should not change the |
1600 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1620 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1601 | to fall back to regular polling again even with inotify, but changes are |
1621 | to fall back to regular polling again even with inotify, but changes are |
1602 | usually detected immediately, and if the file exists there will be no |
1622 | usually detected immediately, and if the file exists there will be no |
1603 | polling. |
1623 | polling. |
|
|
1624 | |
|
|
1625 | =head3 ABI Issues (Largefile Support) |
|
|
1626 | |
|
|
1627 | Libev by default (unless the user overrides this) uses the default |
|
|
1628 | compilation environment, which means that on systems with optionally |
|
|
1629 | disabled large file support, you get the 32 bit version of the stat |
|
|
1630 | structure. When using the library from programs that change the ABI to |
|
|
1631 | use 64 bit file offsets the programs will fail. In that case you have to |
|
|
1632 | compile libev with the same flags to get binary compatibility. This is |
|
|
1633 | obviously the case with any flags that change the ABI, but the problem is |
|
|
1634 | most noticably with ev_stat and largefile support. |
1604 | |
1635 | |
1605 | =head3 Inotify |
1636 | =head3 Inotify |
1606 | |
1637 | |
1607 | When C<inotify (7)> support has been compiled into libev (generally only |
1638 | When C<inotify (7)> support has been compiled into libev (generally only |
1608 | available on Linux) and present at runtime, it will be used to speed up |
1639 | available on Linux) and present at runtime, it will be used to speed up |