… | |
… | |
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 (;;) |
… | |
… | |
255 | =head1 FUNCTIONS CONTROLLING THE EVENT LOOP |
258 | =head1 FUNCTIONS CONTROLLING THE EVENT LOOP |
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 | |
|
|
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 | |
263 | |
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 | |
… | |
… | |
1377 | Simply stops and restarts the periodic watcher again. This is only useful |
1373 | Simply stops and restarts the periodic watcher again. This is only useful |
1378 | when you changed some parameters or the reschedule callback would return |
1374 | when you changed some parameters or the reschedule callback would return |
1379 | a different time than the last time it was called (e.g. in a crond like |
1375 | a different time than the last time it was called (e.g. in a crond like |
1380 | program when the crontabs have changed). |
1376 | program when the crontabs have changed). |
1381 | |
1377 | |
|
|
1378 | =item ev_tstamp ev_periodic_at (ev_periodic *) |
|
|
1379 | |
|
|
1380 | When active, returns the absolute time that the watcher is supposed to |
|
|
1381 | trigger next. |
|
|
1382 | |
1382 | =item ev_tstamp offset [read-write] |
1383 | =item ev_tstamp offset [read-write] |
1383 | |
1384 | |
1384 | When repeating, this contains the offset value, otherwise this is the |
1385 | When repeating, this contains the offset value, otherwise this is the |
1385 | absolute point in time (the C<at> value passed to C<ev_periodic_set>). |
1386 | absolute point in time (the C<at> value passed to C<ev_periodic_set>). |
1386 | |
1387 | |
… | |
… | |
1396 | =item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write] |
1397 | =item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write] |
1397 | |
1398 | |
1398 | The current reschedule callback, or C<0>, if this functionality is |
1399 | The current reschedule callback, or C<0>, if this functionality is |
1399 | switched off. Can be changed any time, but changes only take effect when |
1400 | switched off. Can be changed any time, but changes only take effect when |
1400 | the periodic timer fires or C<ev_periodic_again> is being called. |
1401 | the periodic timer fires or C<ev_periodic_again> is being called. |
1401 | |
|
|
1402 | =item ev_tstamp at [read-only] |
|
|
1403 | |
|
|
1404 | When active, contains the absolute time that the watcher is supposed to |
|
|
1405 | trigger next. |
|
|
1406 | |
1402 | |
1407 | =back |
1403 | =back |
1408 | |
1404 | |
1409 | =head3 Examples |
1405 | =head3 Examples |
1410 | |
1406 | |
… | |
… | |
1638 | 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 |
1639 | 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 |
1640 | change detection where possible. The inotify descriptor will be created lazily |
1636 | change detection where possible. The inotify descriptor will be created lazily |
1641 | when the first C<ev_stat> watcher is being started. |
1637 | when the first C<ev_stat> watcher is being started. |
1642 | |
1638 | |
1643 | 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 |
1644 | 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 |
1645 | 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 |
1646 | 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. |
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 |
1649 | implement this functionality, due to the requirement of having a file |
1645 | implement this functionality, due to the requirement of having a file |
1650 | descriptor open on the object at all times). |
1646 | descriptor open on the object at all times). |
… | |
… | |
2382 | |
2378 | |
2383 | =item * Priorities are not currently supported. Initialising priorities |
2379 | =item * Priorities are not currently supported. Initialising priorities |
2384 | 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 |
2385 | is an ev_pri field. |
2381 | is an ev_pri field. |
2386 | |
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 | |
2387 | =item * Other members are not supported. |
2386 | =item * Other members are not supported. |
2388 | |
2387 | |
2389 | =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 |
2390 | to use the libev header file and library. |
2389 | to use the libev header file and library. |
2391 | |
2390 | |
… | |
… | |
3067 | |
3066 | |
3068 | #include "ev_cpp.h" |
3067 | #include "ev_cpp.h" |
3069 | #include "ev.c" |
3068 | #include "ev.c" |
3070 | |
3069 | |
3071 | |
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 | |
3072 | =head1 COMPLEXITIES |
3128 | =head1 COMPLEXITIES |
3073 | |
3129 | |
3074 | 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 |
3075 | libev will be explained. For complexity discussions about backends see the |
3131 | libev will be explained. For complexity discussions about backends see the |
3076 | documentation for C<ev_default_init>. |
3132 | documentation for C<ev_default_init>. |
… | |
… | |
3204 | calling select (O(n²)) will likely make this unworkable. |
3260 | calling select (O(n²)) will likely make this unworkable. |
3205 | |
3261 | |
3206 | =back |
3262 | =back |
3207 | |
3263 | |
3208 | |
3264 | |
|
|
3265 | =head1 PORTABILITY REQUIREMENTS |
|
|
3266 | |
|
|
3267 | In addition to a working ISO-C implementation, libev relies on a few |
|
|
3268 | additional extensions: |
|
|
3269 | |
|
|
3270 | =over 4 |
|
|
3271 | |
|
|
3272 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
|
|
3273 | |
|
|
3274 | The type C<sig_atomic_t volatile> (or whatever is defined as |
|
|
3275 | C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different |
|
|
3276 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
|
|
3277 | believed to be sufficiently portable. |
|
|
3278 | |
|
|
3279 | =item C<sigprocmask> must work in a threaded environment |
|
|
3280 | |
|
|
3281 | Libev uses C<sigprocmask> to temporarily block signals. This is not |
|
|
3282 | allowed in a threaded program (C<pthread_sigmask> has to be used). Typical |
|
|
3283 | pthread implementations will either allow C<sigprocmask> in the "main |
|
|
3284 | thread" or will block signals process-wide, both behaviours would |
|
|
3285 | be compatible with libev. Interaction between C<sigprocmask> and |
|
|
3286 | C<pthread_sigmask> could complicate things, however. |
|
|
3287 | |
|
|
3288 | The most portable way to handle signals is to block signals in all threads |
|
|
3289 | except the initial one, and run the default loop in the initial thread as |
|
|
3290 | well. |
|
|
3291 | |
|
|
3292 | =back |
|
|
3293 | |
|
|
3294 | If you know of other additional requirements drop me a note. |
|
|
3295 | |
|
|
3296 | |
3209 | =head1 AUTHOR |
3297 | =head1 AUTHOR |
3210 | |
3298 | |
3211 | Marc Lehmann <libev@schmorp.de>. |
3299 | Marc Lehmann <libev@schmorp.de>. |
3212 | |
3300 | |