… | |
… | |
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 |
… | |
… | |
354 | For few fds, this backend is a bit little slower than poll and select, |
358 | For few fds, this backend is a bit little slower than poll and select, |
355 | but it scales phenomenally better. While poll and select usually scale |
359 | but it scales phenomenally better. While poll and select usually scale |
356 | like O(total_fds) where n is the total number of fds (or the highest fd), |
360 | like O(total_fds) where n is the total number of fds (or the highest fd), |
357 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
361 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
358 | of shortcomings, such as silently dropping events in some hard-to-detect |
362 | of shortcomings, such as silently dropping events in some hard-to-detect |
359 | cases and rewiring a syscall per fd change, no fork support and bad |
363 | cases and requiring a syscall per fd change, no fork support and bad |
360 | support for dup. |
364 | support for dup. |
361 | |
365 | |
362 | While stopping, setting and starting an I/O watcher in the same iteration |
366 | While stopping, setting and starting an I/O watcher in the same iteration |
363 | will result in some caching, there is still a syscall per such incident |
367 | will result in some caching, there is still a syscall per such incident |
364 | (because the fd could point to a different file description now), so its |
368 | (because the fd could point to a different file description now), so its |
… | |
… | |
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 |
… | |
… | |
2257 | |
2288 | |
2258 | This call incurs the overhead of a syscall only once per loop iteration, |
2289 | This call incurs the overhead of a syscall only once per loop iteration, |
2259 | so while the overhead might be noticable, it doesn't apply to repeated |
2290 | so while the overhead might be noticable, it doesn't apply to repeated |
2260 | calls to C<ev_async_send>. |
2291 | calls to C<ev_async_send>. |
2261 | |
2292 | |
|
|
2293 | =item bool = ev_async_pending (ev_async *) |
|
|
2294 | |
|
|
2295 | Returns a non-zero value when C<ev_async_send> has been called on the |
|
|
2296 | watcher but the event has not yet been processed (or even noted) by the |
|
|
2297 | event loop. |
|
|
2298 | |
|
|
2299 | C<ev_async_send> sets a flag in the watcher and wakes up the loop. When |
|
|
2300 | the loop iterates next and checks for the watcher to have become active, |
|
|
2301 | it will reset the flag again. C<ev_async_pending> can be used to very |
|
|
2302 | quickly check wether invoking the loop might be a good idea. |
|
|
2303 | |
|
|
2304 | Not that this does I<not> check wether the watcher itself is pending, only |
|
|
2305 | wether it has been requested to make this watcher pending. |
|
|
2306 | |
2262 | =back |
2307 | =back |
2263 | |
2308 | |
2264 | |
2309 | |
2265 | =head1 OTHER FUNCTIONS |
2310 | =head1 OTHER FUNCTIONS |
2266 | |
2311 | |
… | |
… | |
2509 | io.start (fd, ev::READ); |
2554 | io.start (fd, ev::READ); |
2510 | } |
2555 | } |
2511 | }; |
2556 | }; |
2512 | |
2557 | |
2513 | |
2558 | |
|
|
2559 | =head1 OTHER LANGUAGE BINDINGS |
|
|
2560 | |
|
|
2561 | Libev does not offer other language bindings itself, but bindings for a |
|
|
2562 | numbe rof languages exist in the form of third-party packages. If you know |
|
|
2563 | any interesting language binding in addition to the ones listed here, drop |
|
|
2564 | me a note. |
|
|
2565 | |
|
|
2566 | =over 4 |
|
|
2567 | |
|
|
2568 | =item Perl |
|
|
2569 | |
|
|
2570 | The EV module implements the full libev API and is actually used to test |
|
|
2571 | libev. EV is developed together with libev. Apart from the EV core module, |
|
|
2572 | there are additional modules that implement libev-compatible interfaces |
|
|
2573 | to C<libadns> (C<EV::ADNS>), C<Net::SNMP> (C<Net::SNMP::EV>) and the |
|
|
2574 | C<libglib> event core (C<Glib::EV> and C<EV::Glib>). |
|
|
2575 | |
|
|
2576 | It can be found and installed via CPAN, its homepage is found at |
|
|
2577 | L<http://software.schmorp.de/pkg/EV>. |
|
|
2578 | |
|
|
2579 | =item Ruby |
|
|
2580 | |
|
|
2581 | Tony Arcieri has written a ruby extension that offers access to a subset |
|
|
2582 | of the libev API and adds filehandle abstractions, asynchronous DNS and |
|
|
2583 | more on top of it. It can be found via gem servers. Its homepage is at |
|
|
2584 | L<http://rev.rubyforge.org/>. |
|
|
2585 | |
|
|
2586 | =item D |
|
|
2587 | |
|
|
2588 | Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to |
|
|
2589 | be found at L<http://git.llucax.com.ar/?p=software/ev.d.git;a=summary>. |
|
|
2590 | |
|
|
2591 | =back |
|
|
2592 | |
|
|
2593 | |
2514 | =head1 MACRO MAGIC |
2594 | =head1 MACRO MAGIC |
2515 | |
2595 | |
2516 | Libev can be compiled with a variety of options, the most fundamantal |
2596 | Libev can be compiled with a variety of options, the most fundamantal |
2517 | of which is C<EV_MULTIPLICITY>. This option determines whether (most) |
2597 | of which is C<EV_MULTIPLICITY>. This option determines whether (most) |
2518 | functions and callbacks have an initial C<struct ev_loop *> argument. |
2598 | functions and callbacks have an initial C<struct ev_loop *> argument. |
… | |
… | |
2552 | |
2632 | |
2553 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2633 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2554 | |
2634 | |
2555 | Similar to the other two macros, this gives you the value of the default |
2635 | Similar to the other two macros, this gives you the value of the default |
2556 | loop, if multiple loops are supported ("ev loop default"). |
2636 | loop, if multiple loops are supported ("ev loop default"). |
|
|
2637 | |
|
|
2638 | =item C<EV_DEFAULT_UC>, C<EV_DEFAULT_UC_> |
|
|
2639 | |
|
|
2640 | Usage identical to C<EV_DEFAULT> and C<EV_DEFAULT_>, but requires that the |
|
|
2641 | default loop has been initialised (C<UC> == unchecked). Their behaviour |
|
|
2642 | is undefined when the default loop has not been initialised by a previous |
|
|
2643 | execution of C<EV_DEFAULT>, C<EV_DEFAULT_> or C<ev_default_init (...)>. |
|
|
2644 | |
|
|
2645 | It is often prudent to use C<EV_DEFAULT> when initialising the first |
|
|
2646 | watcher in a function but use C<EV_DEFAULT_UC> afterwards. |
2557 | |
2647 | |
2558 | =back |
2648 | =back |
2559 | |
2649 | |
2560 | Example: Declare and initialise a check watcher, utilising the above |
2650 | Example: Declare and initialise a check watcher, utilising the above |
2561 | macros so it will work regardless of whether multiple loops are supported |
2651 | macros so it will work regardless of whether multiple loops are supported |
… | |
… | |
2657 | |
2747 | |
2658 | libev.m4 |
2748 | libev.m4 |
2659 | |
2749 | |
2660 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2750 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2661 | |
2751 | |
2662 | Libev can be configured via a variety of preprocessor symbols you have to define |
2752 | Libev can be configured via a variety of preprocessor symbols you have to |
2663 | before including any of its files. The default is not to build for multiplicity |
2753 | define before including any of its files. The default in the absense of |
2664 | and only include the select backend. |
2754 | autoconf is noted for every option. |
2665 | |
2755 | |
2666 | =over 4 |
2756 | =over 4 |
2667 | |
2757 | |
2668 | =item EV_STANDALONE |
2758 | =item EV_STANDALONE |
2669 | |
2759 | |
… | |
… | |
2695 | =item EV_USE_NANOSLEEP |
2785 | =item EV_USE_NANOSLEEP |
2696 | |
2786 | |
2697 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2787 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2698 | and will use it for delays. Otherwise it will use C<select ()>. |
2788 | and will use it for delays. Otherwise it will use C<select ()>. |
2699 | |
2789 | |
|
|
2790 | =item EV_USE_EVENTFD |
|
|
2791 | |
|
|
2792 | If defined to be C<1>, then libev will assume that C<eventfd ()> is |
|
|
2793 | available and will probe for kernel support at runtime. This will improve |
|
|
2794 | C<ev_signal> and C<ev_async> performance and reduce resource consumption. |
|
|
2795 | If undefined, it will be enabled if the headers indicate GNU/Linux + Glibc |
|
|
2796 | 2.7 or newer, otherwise disabled. |
|
|
2797 | |
2700 | =item EV_USE_SELECT |
2798 | =item EV_USE_SELECT |
2701 | |
2799 | |
2702 | If undefined or defined to be C<1>, libev will compile in support for the |
2800 | If undefined or defined to be C<1>, libev will compile in support for the |
2703 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2801 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2704 | other method takes over, select will be it. Otherwise the select backend |
2802 | other method takes over, select will be it. Otherwise the select backend |
… | |
… | |
2740 | |
2838 | |
2741 | =item EV_USE_EPOLL |
2839 | =item EV_USE_EPOLL |
2742 | |
2840 | |
2743 | If defined to be C<1>, libev will compile in support for the Linux |
2841 | If defined to be C<1>, libev will compile in support for the Linux |
2744 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2842 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2745 | otherwise another method will be used as fallback. This is the |
2843 | otherwise another method will be used as fallback. This is the preferred |
2746 | preferred backend for GNU/Linux systems. |
2844 | backend for GNU/Linux systems. If undefined, it will be enabled if the |
|
|
2845 | headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2747 | |
2846 | |
2748 | =item EV_USE_KQUEUE |
2847 | =item EV_USE_KQUEUE |
2749 | |
2848 | |
2750 | If defined to be C<1>, libev will compile in support for the BSD style |
2849 | If defined to be C<1>, libev will compile in support for the BSD style |
2751 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
2850 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
… | |
… | |
2770 | |
2869 | |
2771 | =item EV_USE_INOTIFY |
2870 | =item EV_USE_INOTIFY |
2772 | |
2871 | |
2773 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2872 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2774 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2873 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2775 | be detected at runtime. |
2874 | be detected at runtime. If undefined, it will be enabled if the headers |
|
|
2875 | indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2776 | |
2876 | |
2777 | =item EV_ATOMIC_T |
2877 | =item EV_ATOMIC_T |
2778 | |
2878 | |
2779 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2879 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2780 | access is atomic with respect to other threads or signal contexts. No such |
2880 | access is atomic with respect to other threads or signal contexts. No such |