… | |
… | |
196 | See the description of C<ev_embed> watchers for more info. |
196 | See the description of C<ev_embed> watchers for more info. |
197 | |
197 | |
198 | =item ev_set_allocator (void *(*cb)(void *ptr, long size)) |
198 | =item ev_set_allocator (void *(*cb)(void *ptr, long size)) |
199 | |
199 | |
200 | Sets the allocation function to use (the prototype is similar - the |
200 | Sets the allocation function to use (the prototype is similar - the |
201 | semantics is identical - to the realloc C function). It is used to |
201 | semantics are identical to the C<realloc> C89/SuS/POSIX function). It is |
202 | allocate and free memory (no surprises here). If it returns zero when |
202 | used to allocate and free memory (no surprises here). If it returns zero |
203 | memory needs to be allocated, the library might abort or take some |
203 | when memory needs to be allocated (C<size != 0>), the library might abort |
204 | potentially destructive action. The default is your system realloc |
204 | or take some potentially destructive action. |
205 | function. |
205 | |
|
|
206 | Since some systems (at least OpenBSD and Darwin) fail to implement |
|
|
207 | correct C<realloc> semantics, libev will use a wrapper around the system |
|
|
208 | C<realloc> and C<free> functions by default. |
206 | |
209 | |
207 | You could override this function in high-availability programs to, say, |
210 | You could override this function in high-availability programs to, say, |
208 | free some memory if it cannot allocate memory, to use a special allocator, |
211 | free some memory if it cannot allocate memory, to use a special allocator, |
209 | or even to sleep a while and retry until some memory is available. |
212 | or even to sleep a while and retry until some memory is available. |
210 | |
213 | |
211 | Example: Replace the libev allocator with one that waits a bit and then |
214 | Example: Replace the libev allocator with one that waits a bit and then |
212 | retries). |
215 | retries (example requires a standards-compliant C<realloc>). |
213 | |
216 | |
214 | static void * |
217 | static void * |
215 | persistent_realloc (void *ptr, size_t size) |
218 | persistent_realloc (void *ptr, size_t size) |
216 | { |
219 | { |
217 | for (;;) |
220 | for (;;) |
… | |
… | |
256 | |
259 | |
257 | An event loop is described by a C<struct ev_loop *>. The library knows two |
260 | An event loop is described by a C<struct ev_loop *>. The library knows two |
258 | types of such loops, the I<default> loop, which supports signals and child |
261 | types of such loops, the I<default> loop, which supports signals and child |
259 | events, and dynamically created loops which do not. |
262 | events, and dynamically created loops which do not. |
260 | |
263 | |
261 | If you use threads, a common model is to run the default event loop |
|
|
262 | in your main thread (or in a separate thread) and for each thread you |
|
|
263 | create, you also create another event loop. Libev itself does no locking |
|
|
264 | whatsoever, so if you mix calls to the same event loop in different |
|
|
265 | threads, make sure you lock (this is usually a bad idea, though, even if |
|
|
266 | done correctly, because it's hideous and inefficient). |
|
|
267 | |
|
|
268 | =over 4 |
264 | =over 4 |
269 | |
265 | |
270 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
266 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
271 | |
267 | |
272 | This will initialise the default event loop if it hasn't been initialised |
268 | This will initialise the default event loop if it hasn't been initialised |
… | |
… | |
274 | false. If it already was initialised it simply returns it (and ignores the |
270 | false. If it already was initialised it simply returns it (and ignores the |
275 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
271 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
276 | |
272 | |
277 | If you don't know what event loop to use, use the one returned from this |
273 | If you don't know what event loop to use, use the one returned from this |
278 | function. |
274 | function. |
|
|
275 | |
|
|
276 | Note that this function is I<not> thread-safe, so if you want to use it |
|
|
277 | from multiple threads, you have to lock (note also that this is unlikely, |
|
|
278 | as loops cannot bes hared easily between threads anyway). |
279 | |
279 | |
280 | The default loop is the only loop that can handle C<ev_signal> and |
280 | 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 |
281 | 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 |
282 | 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 |
283 | create a dynamic loop with C<ev_loop_new> that doesn't do that, or you |
… | |
… | |
354 | For few fds, this backend is a bit little slower than poll and select, |
354 | 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 |
355 | 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), |
356 | 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 |
357 | 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 |
358 | 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 |
359 | cases and requiring a syscall per fd change, no fork support and bad |
360 | support for dup. |
360 | support for dup. |
361 | |
361 | |
362 | While stopping, setting and starting an I/O watcher in the same iteration |
362 | 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 |
363 | 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 |
364 | (because the fd could point to a different file description now), so its |
… | |
… | |
465 | |
465 | |
466 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
466 | 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 |
467 | 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 |
468 | 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). |
469 | undefined behaviour (or a failed assertion if assertions are enabled). |
|
|
470 | |
|
|
471 | Note that this function I<is> thread-safe, and the recommended way to use |
|
|
472 | libev with threads is indeed to create one loop per thread, and using the |
|
|
473 | default loop in the "main" or "initial" thread. |
470 | |
474 | |
471 | Example: Try to create a event loop that uses epoll and nothing else. |
475 | Example: Try to create a event loop that uses epoll and nothing else. |
472 | |
476 | |
473 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
477 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
474 | if (!epoller) |
478 | if (!epoller) |
… | |
… | |
1085 | To support fork in your programs, you either have to call |
1089 | 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, |
1090 | 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 |
1091 | enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or |
1088 | C<EVBACKEND_POLL>. |
1092 | C<EVBACKEND_POLL>. |
1089 | |
1093 | |
|
|
1094 | =head3 The special problem of SIGPIPE |
|
|
1095 | |
|
|
1096 | While not really specific to libev, it is easy to forget about SIGPIPE: |
|
|
1097 | when reading from a pipe whose other end has been closed, your program |
|
|
1098 | gets send a SIGPIPE, which, by default, aborts your program. For most |
|
|
1099 | programs this is sensible behaviour, for daemons, this is usually |
|
|
1100 | undesirable. |
|
|
1101 | |
|
|
1102 | So when you encounter spurious, unexplained daemon exits, make sure you |
|
|
1103 | ignore SIGPIPE (and maybe make sure you log the exit status of your daemon |
|
|
1104 | somewhere, as that would have given you a big clue). |
|
|
1105 | |
1090 | |
1106 | |
1091 | =head3 Watcher-Specific Functions |
1107 | =head3 Watcher-Specific Functions |
1092 | |
1108 | |
1093 | =over 4 |
1109 | =over 4 |
1094 | |
1110 | |
… | |
… | |
1600 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1616 | 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 |
1617 | 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 |
1618 | usually detected immediately, and if the file exists there will be no |
1603 | polling. |
1619 | polling. |
1604 | |
1620 | |
|
|
1621 | =head3 ABI Issues (Largefile Support) |
|
|
1622 | |
|
|
1623 | Libev by default (unless the user overrides this) uses the default |
|
|
1624 | compilation environment, which means that on systems with optionally |
|
|
1625 | disabled large file support, you get the 32 bit version of the stat |
|
|
1626 | structure. When using the library from programs that change the ABI to |
|
|
1627 | use 64 bit file offsets the programs will fail. In that case you have to |
|
|
1628 | compile libev with the same flags to get binary compatibility. This is |
|
|
1629 | obviously the case with any flags that change the ABI, but the problem is |
|
|
1630 | most noticably with ev_stat and largefile support. |
|
|
1631 | |
1605 | =head3 Inotify |
1632 | =head3 Inotify |
1606 | |
1633 | |
1607 | When C<inotify (7)> support has been compiled into libev (generally only |
1634 | 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 |
1635 | available on Linux) and present at runtime, it will be used to speed up |
1609 | change detection where possible. The inotify descriptor will be created lazily |
1636 | change detection where possible. The inotify descriptor will be created lazily |
1610 | when the first C<ev_stat> watcher is being started. |
1637 | when the first C<ev_stat> watcher is being started. |
1611 | |
1638 | |
1612 | Inotify presense does not change the semantics of C<ev_stat> watchers |
1639 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1613 | except that changes might be detected earlier, and in some cases, to avoid |
1640 | except that changes might be detected earlier, and in some cases, to avoid |
1614 | making regular C<stat> calls. Even in the presense of inotify support |
1641 | making regular C<stat> calls. Even in the presence of inotify support |
1615 | there are many cases where libev has to resort to regular C<stat> polling. |
1642 | there are many cases where libev has to resort to regular C<stat> polling. |
1616 | |
1643 | |
1617 | (There is no support for kqueue, as apparently it cannot be used to |
1644 | (There is no support for kqueue, as apparently it cannot be used to |
1618 | implement this functionality, due to the requirement of having a file |
1645 | implement this functionality, due to the requirement of having a file |
1619 | descriptor open on the object at all times). |
1646 | descriptor open on the object at all times). |
… | |
… | |
2257 | |
2284 | |
2258 | This call incurs the overhead of a syscall only once per loop iteration, |
2285 | 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 |
2286 | so while the overhead might be noticable, it doesn't apply to repeated |
2260 | calls to C<ev_async_send>. |
2287 | calls to C<ev_async_send>. |
2261 | |
2288 | |
|
|
2289 | =item bool = ev_async_pending (ev_async *) |
|
|
2290 | |
|
|
2291 | Returns a non-zero value when C<ev_async_send> has been called on the |
|
|
2292 | watcher but the event has not yet been processed (or even noted) by the |
|
|
2293 | event loop. |
|
|
2294 | |
|
|
2295 | C<ev_async_send> sets a flag in the watcher and wakes up the loop. When |
|
|
2296 | the loop iterates next and checks for the watcher to have become active, |
|
|
2297 | it will reset the flag again. C<ev_async_pending> can be used to very |
|
|
2298 | quickly check wether invoking the loop might be a good idea. |
|
|
2299 | |
|
|
2300 | Not that this does I<not> check wether the watcher itself is pending, only |
|
|
2301 | wether it has been requested to make this watcher pending. |
|
|
2302 | |
2262 | =back |
2303 | =back |
2263 | |
2304 | |
2264 | |
2305 | |
2265 | =head1 OTHER FUNCTIONS |
2306 | =head1 OTHER FUNCTIONS |
2266 | |
2307 | |
… | |
… | |
2337 | |
2378 | |
2338 | =item * Priorities are not currently supported. Initialising priorities |
2379 | =item * Priorities are not currently supported. Initialising priorities |
2339 | will fail and all watchers will have the same priority, even though there |
2380 | will fail and all watchers will have the same priority, even though there |
2340 | is an ev_pri field. |
2381 | is an ev_pri field. |
2341 | |
2382 | |
|
|
2383 | =item * In libevent, the last base created gets the signals, in libev, the |
|
|
2384 | first base created (== the default loop) gets the signals. |
|
|
2385 | |
2342 | =item * Other members are not supported. |
2386 | =item * Other members are not supported. |
2343 | |
2387 | |
2344 | =item * The libev emulation is I<not> ABI compatible to libevent, you need |
2388 | =item * The libev emulation is I<not> ABI compatible to libevent, you need |
2345 | to use the libev header file and library. |
2389 | to use the libev header file and library. |
2346 | |
2390 | |
… | |
… | |
2588 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2632 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2589 | |
2633 | |
2590 | Similar to the other two macros, this gives you the value of the default |
2634 | Similar to the other two macros, this gives you the value of the default |
2591 | loop, if multiple loops are supported ("ev loop default"). |
2635 | loop, if multiple loops are supported ("ev loop default"). |
2592 | |
2636 | |
|
|
2637 | =item C<EV_DEFAULT_UC>, C<EV_DEFAULT_UC_> |
|
|
2638 | |
|
|
2639 | Usage identical to C<EV_DEFAULT> and C<EV_DEFAULT_>, but requires that the |
|
|
2640 | default loop has been initialised (C<UC> == unchecked). Their behaviour |
|
|
2641 | is undefined when the default loop has not been initialised by a previous |
|
|
2642 | execution of C<EV_DEFAULT>, C<EV_DEFAULT_> or C<ev_default_init (...)>. |
|
|
2643 | |
|
|
2644 | It is often prudent to use C<EV_DEFAULT> when initialising the first |
|
|
2645 | watcher in a function but use C<EV_DEFAULT_UC> afterwards. |
|
|
2646 | |
2593 | =back |
2647 | =back |
2594 | |
2648 | |
2595 | Example: Declare and initialise a check watcher, utilising the above |
2649 | Example: Declare and initialise a check watcher, utilising the above |
2596 | macros so it will work regardless of whether multiple loops are supported |
2650 | macros so it will work regardless of whether multiple loops are supported |
2597 | or not. |
2651 | or not. |
… | |
… | |
2692 | |
2746 | |
2693 | libev.m4 |
2747 | libev.m4 |
2694 | |
2748 | |
2695 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2749 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2696 | |
2750 | |
2697 | Libev can be configured via a variety of preprocessor symbols you have to define |
2751 | Libev can be configured via a variety of preprocessor symbols you have to |
2698 | before including any of its files. The default is not to build for multiplicity |
2752 | define before including any of its files. The default in the absense of |
2699 | and only include the select backend. |
2753 | autoconf is noted for every option. |
2700 | |
2754 | |
2701 | =over 4 |
2755 | =over 4 |
2702 | |
2756 | |
2703 | =item EV_STANDALONE |
2757 | =item EV_STANDALONE |
2704 | |
2758 | |
… | |
… | |
2730 | =item EV_USE_NANOSLEEP |
2784 | =item EV_USE_NANOSLEEP |
2731 | |
2785 | |
2732 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2786 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2733 | and will use it for delays. Otherwise it will use C<select ()>. |
2787 | and will use it for delays. Otherwise it will use C<select ()>. |
2734 | |
2788 | |
|
|
2789 | =item EV_USE_EVENTFD |
|
|
2790 | |
|
|
2791 | If defined to be C<1>, then libev will assume that C<eventfd ()> is |
|
|
2792 | available and will probe for kernel support at runtime. This will improve |
|
|
2793 | C<ev_signal> and C<ev_async> performance and reduce resource consumption. |
|
|
2794 | If undefined, it will be enabled if the headers indicate GNU/Linux + Glibc |
|
|
2795 | 2.7 or newer, otherwise disabled. |
|
|
2796 | |
2735 | =item EV_USE_SELECT |
2797 | =item EV_USE_SELECT |
2736 | |
2798 | |
2737 | If undefined or defined to be C<1>, libev will compile in support for the |
2799 | If undefined or defined to be C<1>, libev will compile in support for the |
2738 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2800 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2739 | other method takes over, select will be it. Otherwise the select backend |
2801 | other method takes over, select will be it. Otherwise the select backend |
… | |
… | |
2775 | |
2837 | |
2776 | =item EV_USE_EPOLL |
2838 | =item EV_USE_EPOLL |
2777 | |
2839 | |
2778 | If defined to be C<1>, libev will compile in support for the Linux |
2840 | If defined to be C<1>, libev will compile in support for the Linux |
2779 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2841 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2780 | otherwise another method will be used as fallback. This is the |
2842 | otherwise another method will be used as fallback. This is the preferred |
2781 | preferred backend for GNU/Linux systems. |
2843 | backend for GNU/Linux systems. If undefined, it will be enabled if the |
|
|
2844 | headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2782 | |
2845 | |
2783 | =item EV_USE_KQUEUE |
2846 | =item EV_USE_KQUEUE |
2784 | |
2847 | |
2785 | If defined to be C<1>, libev will compile in support for the BSD style |
2848 | If defined to be C<1>, libev will compile in support for the BSD style |
2786 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
2849 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
… | |
… | |
2805 | |
2868 | |
2806 | =item EV_USE_INOTIFY |
2869 | =item EV_USE_INOTIFY |
2807 | |
2870 | |
2808 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2871 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2809 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2872 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2810 | be detected at runtime. |
2873 | be detected at runtime. If undefined, it will be enabled if the headers |
|
|
2874 | indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2811 | |
2875 | |
2812 | =item EV_ATOMIC_T |
2876 | =item EV_ATOMIC_T |
2813 | |
2877 | |
2814 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2878 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2815 | access is atomic with respect to other threads or signal contexts. No such |
2879 | access is atomic with respect to other threads or signal contexts. No such |
… | |
… | |
3002 | |
3066 | |
3003 | #include "ev_cpp.h" |
3067 | #include "ev_cpp.h" |
3004 | #include "ev.c" |
3068 | #include "ev.c" |
3005 | |
3069 | |
3006 | |
3070 | |
|
|
3071 | =head1 THREADS AND COROUTINES |
|
|
3072 | |
|
|
3073 | =head2 THREADS |
|
|
3074 | |
|
|
3075 | Libev itself is completely threadsafe, but it uses no locking. This |
|
|
3076 | means that you can use as many loops as you want in parallel, as long as |
|
|
3077 | only one thread ever calls into one libev function with the same loop |
|
|
3078 | parameter. |
|
|
3079 | |
|
|
3080 | Or put differently: calls with different loop parameters can be done in |
|
|
3081 | parallel from multiple threads, calls with the same loop parameter must be |
|
|
3082 | done serially (but can be done from different threads, as long as only one |
|
|
3083 | thread ever is inside a call at any point in time, e.g. by using a mutex |
|
|
3084 | per loop). |
|
|
3085 | |
|
|
3086 | If you want to know which design is best for your problem, then I cannot |
|
|
3087 | help you but by giving some generic advice: |
|
|
3088 | |
|
|
3089 | =over 4 |
|
|
3090 | |
|
|
3091 | =item * most applications have a main thread: use the default libev loop |
|
|
3092 | in that thread, or create a seperate thread running only the default loop. |
|
|
3093 | |
|
|
3094 | This helps integrating other libraries or software modules that use libev |
|
|
3095 | themselves and don't care/know about threading. |
|
|
3096 | |
|
|
3097 | =item * one loop per thread is usually a good model. |
|
|
3098 | |
|
|
3099 | Doing this is almost never wrong, sometimes a better-performance model |
|
|
3100 | exists, but it is always a good start. |
|
|
3101 | |
|
|
3102 | =item * other models exist, such as the leader/follower pattern, where one |
|
|
3103 | loop is handed through multiple threads in a kind of round-robbin fashion. |
|
|
3104 | |
|
|
3105 | Chosing a model is hard - look around, learn, know that usually you cna do |
|
|
3106 | better than you currently do :-) |
|
|
3107 | |
|
|
3108 | =item * often you need to talk to some other thread which blocks in the |
|
|
3109 | event loop - C<ev_async> watchers can be used to wake them up from other |
|
|
3110 | threads safely (or from signal contexts...). |
|
|
3111 | |
|
|
3112 | =back |
|
|
3113 | |
|
|
3114 | =head2 COROUTINES |
|
|
3115 | |
|
|
3116 | Libev is much more accomodating to coroutines ("cooperative threads"): |
|
|
3117 | libev fully supports nesting calls to it's functions from different |
|
|
3118 | coroutines (e.g. you can call C<ev_loop> on the same loop from two |
|
|
3119 | different coroutines and switch freely between both coroutines running the |
|
|
3120 | loop, as long as you don't confuse yourself). The only exception is that |
|
|
3121 | you must not do this from C<ev_periodic> reschedule callbacks. |
|
|
3122 | |
|
|
3123 | Care has been invested into making sure that libev does not keep local |
|
|
3124 | state inside C<ev_loop>, and other calls do not usually allow coroutine |
|
|
3125 | switches. |
|
|
3126 | |
|
|
3127 | |
3007 | =head1 COMPLEXITIES |
3128 | =head1 COMPLEXITIES |
3008 | |
3129 | |
3009 | In this section the complexities of (many of) the algorithms used inside |
3130 | In this section the complexities of (many of) the algorithms used inside |
3010 | libev will be explained. For complexity discussions about backends see the |
3131 | libev will be explained. For complexity discussions about backends see the |
3011 | documentation for C<ev_default_init>. |
3132 | documentation for C<ev_default_init>. |