ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.139 by root, Wed Apr 2 05:51:40 2008 UTC vs.
Revision 1.148 by root, Thu Apr 24 01:42:11 2008 UTC

196See the description of C<ev_embed> watchers for more info. 196See 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
200Sets the allocation function to use (the prototype is similar - the 200Sets the allocation function to use (the prototype is similar - the
201semantics is identical - to the realloc C function). It is used to 201semantics are identical to the C<realloc> C89/SuS/POSIX function). It is
202allocate and free memory (no surprises here). If it returns zero when 202used to allocate and free memory (no surprises here). If it returns zero
203memory needs to be allocated, the library might abort or take some 203when memory needs to be allocated (C<size != 0>), the library might abort
204potentially destructive action. The default is your system realloc 204or take some potentially destructive action.
205function. 205
206Since some systems (at least OpenBSD and Darwin) fail to implement
207correct C<realloc> semantics, libev will use a wrapper around the system
208C<realloc> and C<free> functions by default.
206 209
207You could override this function in high-availability programs to, say, 210You could override this function in high-availability programs to, say,
208free some memory if it cannot allocate memory, to use a special allocator, 211free some memory if it cannot allocate memory, to use a special allocator,
209or even to sleep a while and retry until some memory is available. 212or even to sleep a while and retry until some memory is available.
210 213
211Example: Replace the libev allocator with one that waits a bit and then 214Example: Replace the libev allocator with one that waits a bit and then
212retries). 215retries (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
257An event loop is described by a C<struct ev_loop *>. The library knows two 260An event loop is described by a C<struct ev_loop *>. The library knows two
258types of such loops, the I<default> loop, which supports signals and child 261types of such loops, the I<default> loop, which supports signals and child
259events, and dynamically created loops which do not. 262events, and dynamically created loops which do not.
260 263
261If you use threads, a common model is to run the default event loop
262in your main thread (or in a separate thread) and for each thread you
263create, you also create another event loop. Libev itself does no locking
264whatsoever, so if you mix calls to the same event loop in different
265threads, make sure you lock (this is usually a bad idea, though, even if
266done 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
272This will initialise the default event loop if it hasn't been initialised 268This will initialise the default event loop if it hasn't been initialised
358For few fds, this backend is a bit little slower than poll and select, 354For few fds, this backend is a bit little slower than poll and select,
359but it scales phenomenally better. While poll and select usually scale 355but it scales phenomenally better. While poll and select usually scale
360like O(total_fds) where n is the total number of fds (or the highest fd), 356like O(total_fds) where n is the total number of fds (or the highest fd),
361epoll scales either O(1) or O(active_fds). The epoll design has a number 357epoll scales either O(1) or O(active_fds). The epoll design has a number
362of shortcomings, such as silently dropping events in some hard-to-detect 358of shortcomings, such as silently dropping events in some hard-to-detect
363cases and rewiring a syscall per fd change, no fork support and bad 359cases and requiring a syscall per fd change, no fork support and bad
364support for dup. 360support for dup.
365 361
366While stopping, setting and starting an I/O watcher in the same iteration 362While stopping, setting and starting an I/O watcher in the same iteration
367will result in some caching, there is still a syscall per such incident 363will result in some caching, there is still a syscall per such incident
368(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
1638When C<inotify (7)> support has been compiled into libev (generally only 1634When C<inotify (7)> support has been compiled into libev (generally only
1639available on Linux) and present at runtime, it will be used to speed up 1635available on Linux) and present at runtime, it will be used to speed up
1640change detection where possible. The inotify descriptor will be created lazily 1636change detection where possible. The inotify descriptor will be created lazily
1641when the first C<ev_stat> watcher is being started. 1637when the first C<ev_stat> watcher is being started.
1642 1638
1643Inotify presense does not change the semantics of C<ev_stat> watchers 1639Inotify presence does not change the semantics of C<ev_stat> watchers
1644except that changes might be detected earlier, and in some cases, to avoid 1640except that changes might be detected earlier, and in some cases, to avoid
1645making regular C<stat> calls. Even in the presense of inotify support 1641making regular C<stat> calls. Even in the presence of inotify support
1646there are many cases where libev has to resort to regular C<stat> polling. 1642there are many cases where libev has to resort to regular C<stat> polling.
1647 1643
1648(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
1649implement this functionality, due to the requirement of having a file 1645implement this functionality, due to the requirement of having a file
1650descriptor open on the object at all times). 1646descriptor open on the object at all times).
2288 2284
2289This call incurs the overhead of a syscall only once per loop iteration, 2285This call incurs the overhead of a syscall only once per loop iteration,
2290so while the overhead might be noticable, it doesn't apply to repeated 2286so while the overhead might be noticable, it doesn't apply to repeated
2291calls to C<ev_async_send>. 2287calls to C<ev_async_send>.
2292 2288
2289=item bool = ev_async_pending (ev_async *)
2290
2291Returns a non-zero value when C<ev_async_send> has been called on the
2292watcher but the event has not yet been processed (or even noted) by the
2293event loop.
2294
2295C<ev_async_send> sets a flag in the watcher and wakes up the loop. When
2296the loop iterates next and checks for the watcher to have become active,
2297it will reset the flag again. C<ev_async_pending> can be used to very
2298quickly check wether invoking the loop might be a good idea.
2299
2300Not that this does I<not> check wether the watcher itself is pending, only
2301wether it has been requested to make this watcher pending.
2302
2293=back 2303=back
2294 2304
2295 2305
2296=head1 OTHER FUNCTIONS 2306=head1 OTHER FUNCTIONS
2297 2307
2368 2378
2369=item * Priorities are not currently supported. Initialising priorities 2379=item * Priorities are not currently supported. Initialising priorities
2370will fail and all watchers will have the same priority, even though there 2380will fail and all watchers will have the same priority, even though there
2371is an ev_pri field. 2381is an ev_pri field.
2372 2382
2383=item * In libevent, the last base created gets the signals, in libev, the
2384first base created (== the default loop) gets the signals.
2385
2373=item * Other members are not supported. 2386=item * Other members are not supported.
2374 2387
2375=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
2376to use the libev header file and library. 2389to use the libev header file and library.
2377 2390
2619=item C<EV_DEFAULT>, C<EV_DEFAULT_> 2632=item C<EV_DEFAULT>, C<EV_DEFAULT_>
2620 2633
2621Similar to the other two macros, this gives you the value of the default 2634Similar to the other two macros, this gives you the value of the default
2622loop, if multiple loops are supported ("ev loop default"). 2635loop, if multiple loops are supported ("ev loop default").
2623 2636
2637=item C<EV_DEFAULT_UC>, C<EV_DEFAULT_UC_>
2638
2639Usage identical to C<EV_DEFAULT> and C<EV_DEFAULT_>, but requires that the
2640default loop has been initialised (C<UC> == unchecked). Their behaviour
2641is undefined when the default loop has not been initialised by a previous
2642execution of C<EV_DEFAULT>, C<EV_DEFAULT_> or C<ev_default_init (...)>.
2643
2644It is often prudent to use C<EV_DEFAULT> when initialising the first
2645watcher in a function but use C<EV_DEFAULT_UC> afterwards.
2646
2624=back 2647=back
2625 2648
2626Example: Declare and initialise a check watcher, utilising the above 2649Example: Declare and initialise a check watcher, utilising the above
2627macros so it will work regardless of whether multiple loops are supported 2650macros so it will work regardless of whether multiple loops are supported
2628or not. 2651or not.
2723 2746
2724 libev.m4 2747 libev.m4
2725 2748
2726=head2 PREPROCESSOR SYMBOLS/MACROS 2749=head2 PREPROCESSOR SYMBOLS/MACROS
2727 2750
2728Libev can be configured via a variety of preprocessor symbols you have to define 2751Libev can be configured via a variety of preprocessor symbols you have to
2729before including any of its files. The default is not to build for multiplicity 2752define before including any of its files. The default in the absense of
2730and only include the select backend. 2753autoconf is noted for every option.
2731 2754
2732=over 4 2755=over 4
2733 2756
2734=item EV_STANDALONE 2757=item EV_STANDALONE
2735 2758
2761=item EV_USE_NANOSLEEP 2784=item EV_USE_NANOSLEEP
2762 2785
2763If defined to be C<1>, libev will assume that C<nanosleep ()> is available 2786If defined to be C<1>, libev will assume that C<nanosleep ()> is available
2764and will use it for delays. Otherwise it will use C<select ()>. 2787and will use it for delays. Otherwise it will use C<select ()>.
2765 2788
2789=item EV_USE_EVENTFD
2790
2791If defined to be C<1>, then libev will assume that C<eventfd ()> is
2792available and will probe for kernel support at runtime. This will improve
2793C<ev_signal> and C<ev_async> performance and reduce resource consumption.
2794If undefined, it will be enabled if the headers indicate GNU/Linux + Glibc
27952.7 or newer, otherwise disabled.
2796
2766=item EV_USE_SELECT 2797=item EV_USE_SELECT
2767 2798
2768If undefined or defined to be C<1>, libev will compile in support for the 2799If undefined or defined to be C<1>, libev will compile in support for the
2769C<select>(2) backend. No attempt at autodetection will be done: if no 2800C<select>(2) backend. No attempt at autodetection will be done: if no
2770other method takes over, select will be it. Otherwise the select backend 2801other method takes over, select will be it. Otherwise the select backend
2806 2837
2807=item EV_USE_EPOLL 2838=item EV_USE_EPOLL
2808 2839
2809If defined to be C<1>, libev will compile in support for the Linux 2840If defined to be C<1>, libev will compile in support for the Linux
2810C<epoll>(7) backend. Its availability will be detected at runtime, 2841C<epoll>(7) backend. Its availability will be detected at runtime,
2811otherwise another method will be used as fallback. This is the 2842otherwise another method will be used as fallback. This is the preferred
2812preferred backend for GNU/Linux systems. 2843backend for GNU/Linux systems. If undefined, it will be enabled if the
2844headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
2813 2845
2814=item EV_USE_KQUEUE 2846=item EV_USE_KQUEUE
2815 2847
2816If defined to be C<1>, libev will compile in support for the BSD style 2848If defined to be C<1>, libev will compile in support for the BSD style
2817C<kqueue>(2) backend. Its actual availability will be detected at runtime, 2849C<kqueue>(2) backend. Its actual availability will be detected at runtime,
2836 2868
2837=item EV_USE_INOTIFY 2869=item EV_USE_INOTIFY
2838 2870
2839If defined to be C<1>, libev will compile in support for the Linux inotify 2871If defined to be C<1>, libev will compile in support for the Linux inotify
2840interface to speed up C<ev_stat> watchers. Its actual availability will 2872interface to speed up C<ev_stat> watchers. Its actual availability will
2841be detected at runtime. 2873be detected at runtime. If undefined, it will be enabled if the headers
2874indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
2842 2875
2843=item EV_ATOMIC_T 2876=item EV_ATOMIC_T
2844 2877
2845Libev requires an integer type (suitable for storing C<0> or C<1>) whose 2878Libev requires an integer type (suitable for storing C<0> or C<1>) whose
2846access is atomic with respect to other threads or signal contexts. No such 2879access is atomic with respect to other threads or signal contexts. No such
3033 3066
3034 #include "ev_cpp.h" 3067 #include "ev_cpp.h"
3035 #include "ev.c" 3068 #include "ev.c"
3036 3069
3037 3070
3071=head1 THREADS AND COROUTINES
3072
3073=head2 THREADS
3074
3075Libev itself is completely threadsafe, but it uses no locking. This
3076means that you can use as many loops as you want in parallel, as long as
3077only one thread ever calls into one libev function with the same loop
3078parameter.
3079
3080Or put differently: calls with different loop parameters can be done in
3081parallel from multiple threads, calls with the same loop parameter must be
3082done serially (but can be done from different threads, as long as only one
3083thread ever is inside a call at any point in time, e.g. by using a mutex
3084per loop).
3085
3086If you want to know which design is best for your problem, then I cannot
3087help 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
3092in that thread, or create a seperate thread running only the default loop.
3093
3094This helps integrating other libraries or software modules that use libev
3095themselves and don't care/know about threading.
3096
3097=item * one loop per thread is usually a good model.
3098
3099Doing this is almost never wrong, sometimes a better-performance model
3100exists, but it is always a good start.
3101
3102=item * other models exist, such as the leader/follower pattern, where one
3103loop is handed through multiple threads in a kind of round-robbin fashion.
3104
3105Chosing a model is hard - look around, learn, know that usually you cna do
3106better than you currently do :-)
3107
3108=item * often you need to talk to some other thread which blocks in the
3109event loop - C<ev_async> watchers can be used to wake them up from other
3110threads safely (or from signal contexts...).
3111
3112=back
3113
3114=head2 COROUTINES
3115
3116Libev is much more accomodating to coroutines ("cooperative threads"):
3117libev fully supports nesting calls to it's functions from different
3118coroutines (e.g. you can call C<ev_loop> on the same loop from two
3119different coroutines and switch freely between both coroutines running the
3120loop, as long as you don't confuse yourself). The only exception is that
3121you must not do this from C<ev_periodic> reschedule callbacks.
3122
3123Care has been invested into making sure that libev does not keep local
3124state inside C<ev_loop>, and other calls do not usually allow coroutine
3125switches.
3126
3127
3038=head1 COMPLEXITIES 3128=head1 COMPLEXITIES
3039 3129
3040In this section the complexities of (many of) the algorithms used inside 3130In this section the complexities of (many of) the algorithms used inside
3041libev will be explained. For complexity discussions about backends see the 3131libev will be explained. For complexity discussions about backends see the
3042documentation for C<ev_default_init>. 3132documentation for C<ev_default_init>.
3170calling select (O(n²)) will likely make this unworkable. 3260calling select (O(n²)) will likely make this unworkable.
3171 3261
3172=back 3262=back
3173 3263
3174 3264
3265=head1 PORTABILITY REQUIREMENTS
3266
3267In addition to a working ISO-C implementation, libev relies on a few
3268additional extensions:
3269
3270=over 4
3271
3272=item C<sig_atomic_t volatile> must be thread-atomic as well
3273
3274The type C<sig_atomic_t volatile> (or whatever is defined as
3275C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different
3276threads. This is not part of the specification for C<sig_atomic_t>, but is
3277believed to be sufficiently portable.
3278
3279=item C<sigprocmask> must work in a threaded environment
3280
3281Libev uses C<sigprocmask> to temporarily block signals. This is not
3282allowed in a threaded program (C<pthread_sigmask> has to be used). Typical
3283pthread implementations will either allow C<sigprocmask> in the "main
3284thread" or will block signals process-wide, both behaviours would
3285be compatible with libev. Interaction between C<sigprocmask> and
3286C<pthread_sigmask> could complicate things, however.
3287
3288The most portable way to handle signals is to block signals in all threads
3289except the initial one, and run the default loop in the initial thread as
3290well.
3291
3292=back
3293
3294If you know of other additional requirements drop me a note.
3295
3296
3175=head1 AUTHOR 3297=head1 AUTHOR
3176 3298
3177Marc Lehmann <libev@schmorp.de>. 3299Marc Lehmann <libev@schmorp.de>.
3178 3300

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines