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

Comparing libev/ev.pod (file contents):
Revision 1.30 by root, Fri Nov 23 04:36:03 2007 UTC vs.
Revision 1.60 by root, Wed Nov 28 18:29:30 2007 UTC

3libev - a high performance full-featured event loop written in C 3libev - a high performance full-featured event loop written in C
4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 #include <ev.h> 7 #include <ev.h>
8
9=head1 EXAMPLE PROGRAM
10
11 #include <ev.h>
12
13 ev_io stdin_watcher;
14 ev_timer timeout_watcher;
15
16 /* called when data readable on stdin */
17 static void
18 stdin_cb (EV_P_ struct ev_io *w, int revents)
19 {
20 /* puts ("stdin ready"); */
21 ev_io_stop (EV_A_ w); /* just a syntax example */
22 ev_unloop (EV_A_ EVUNLOOP_ALL); /* leave all loop calls */
23 }
24
25 static void
26 timeout_cb (EV_P_ struct ev_timer *w, int revents)
27 {
28 /* puts ("timeout"); */
29 ev_unloop (EV_A_ EVUNLOOP_ONE); /* leave one loop call */
30 }
31
32 int
33 main (void)
34 {
35 struct ev_loop *loop = ev_default_loop (0);
36
37 /* initialise an io watcher, then start it */
38 ev_io_init (&stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ);
39 ev_io_start (loop, &stdin_watcher);
40
41 /* simple non-repeating 5.5 second timeout */
42 ev_timer_init (&timeout_watcher, timeout_cb, 5.5, 0.);
43 ev_timer_start (loop, &timeout_watcher);
44
45 /* loop till timeout or data ready */
46 ev_loop (loop, 0);
47
48 return 0;
49 }
8 50
9=head1 DESCRIPTION 51=head1 DESCRIPTION
10 52
11Libev is an event loop: you register interest in certain events (such as a 53Libev is an event loop: you register interest in certain events (such as a
12file descriptor being readable or a timeout occuring), and it will manage 54file descriptor being readable or a timeout occuring), and it will manage
21details of the event, and then hand it over to libev by I<starting> the 63details of the event, and then hand it over to libev by I<starting> the
22watcher. 64watcher.
23 65
24=head1 FEATURES 66=head1 FEATURES
25 67
26Libev supports select, poll, the linux-specific epoll and the bsd-specific 68Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the
27kqueue mechanisms for file descriptor events, relative timers, absolute 69BSD-specific C<kqueue> and the Solaris-specific event port mechanisms
28timers with customised rescheduling, signal events, process status change 70for file descriptor events (C<ev_io>), the Linux C<inotify> interface
29events (related to SIGCHLD), and event watchers dealing with the event 71(for C<ev_stat>), relative timers (C<ev_timer>), absolute timers
30loop mechanism itself (idle, prepare and check watchers). It also is quite 72with customised rescheduling (C<ev_periodic>), synchronous signals
73(C<ev_signal>), process status change events (C<ev_child>), and event
74watchers dealing with the event loop mechanism itself (C<ev_idle>,
75C<ev_embed>, C<ev_prepare> and C<ev_check> watchers) as well as
76file watchers (C<ev_stat>) and even limited support for fork events
77(C<ev_fork>).
78
79It also is quite fast (see this
31fast (see this L<benchmark|http://libev.schmorp.de/bench.html> comparing 80L<benchmark|http://libev.schmorp.de/bench.html> comparing it to libevent
32it to libevent for example). 81for example).
33 82
34=head1 CONVENTIONS 83=head1 CONVENTIONS
35 84
36Libev is very configurable. In this manual the default configuration 85Libev is very configurable. In this manual the default configuration will
37will be described, which supports multiple event loops. For more info 86be described, which supports multiple event loops. For more info about
38about various configuration options please have a look at the file 87various configuration options please have a look at B<EMBED> section in
39F<README.embed> in the libev distribution. If libev was configured without 88this manual. If libev was configured without support for multiple event
40support for multiple event loops, then all functions taking an initial 89loops, then all functions taking an initial argument of name C<loop>
41argument of name C<loop> (which is always of type C<struct ev_loop *>) 90(which is always of type C<struct ev_loop *>) will not have this argument.
42will not have this argument.
43 91
44=head1 TIME REPRESENTATION 92=head1 TIME REPRESENTATION
45 93
46Libev represents time as a single floating point number, representing the 94Libev represents time as a single floating point number, representing the
47(fractional) number of seconds since the (POSIX) epoch (somewhere near 95(fractional) number of seconds since the (POSIX) epoch (somewhere near
48the beginning of 1970, details are complicated, don't ask). This type is 96the beginning of 1970, details are complicated, don't ask). This type is
49called C<ev_tstamp>, which is what you should use too. It usually aliases 97called C<ev_tstamp>, which is what you should use too. It usually aliases
50to the double type in C. 98to the C<double> type in C, and when you need to do any calculations on
99it, you should treat it as such.
51 100
52=head1 GLOBAL FUNCTIONS 101=head1 GLOBAL FUNCTIONS
53 102
54These functions can be called anytime, even before initialising the 103These functions can be called anytime, even before initialising the
55library in any way. 104library in any way.
75Usually, it's a good idea to terminate if the major versions mismatch, 124Usually, it's a good idea to terminate if the major versions mismatch,
76as this indicates an incompatible change. Minor versions are usually 125as this indicates an incompatible change. Minor versions are usually
77compatible to older versions, so a larger minor version alone is usually 126compatible to older versions, so a larger minor version alone is usually
78not a problem. 127not a problem.
79 128
129Example: Make sure we haven't accidentally been linked against the wrong
130version.
131
132 assert (("libev version mismatch",
133 ev_version_major () == EV_VERSION_MAJOR
134 && ev_version_minor () >= EV_VERSION_MINOR));
135
136=item unsigned int ev_supported_backends ()
137
138Return the set of all backends (i.e. their corresponding C<EV_BACKEND_*>
139value) compiled into this binary of libev (independent of their
140availability on the system you are running on). See C<ev_default_loop> for
141a description of the set values.
142
143Example: make sure we have the epoll method, because yeah this is cool and
144a must have and can we have a torrent of it please!!!11
145
146 assert (("sorry, no epoll, no sex",
147 ev_supported_backends () & EVBACKEND_EPOLL));
148
149=item unsigned int ev_recommended_backends ()
150
151Return the set of all backends compiled into this binary of libev and also
152recommended for this platform. This set is often smaller than the one
153returned by C<ev_supported_backends>, as for example kqueue is broken on
154most BSDs and will not be autodetected unless you explicitly request it
155(assuming you know what you are doing). This is the set of backends that
156libev will probe for if you specify no backends explicitly.
157
158=item unsigned int ev_embeddable_backends ()
159
160Returns the set of backends that are embeddable in other event loops. This
161is the theoretical, all-platform, value. To find which backends
162might be supported on the current system, you would need to look at
163C<ev_embeddable_backends () & ev_supported_backends ()>, likewise for
164recommended ones.
165
166See the description of C<ev_embed> watchers for more info.
167
80=item ev_set_allocator (void *(*cb)(void *ptr, long size)) 168=item ev_set_allocator (void *(*cb)(void *ptr, long size))
81 169
82Sets the allocation function to use (the prototype is similar to the 170Sets the allocation function to use (the prototype is similar - the
83realloc C function, the semantics are identical). It is used to allocate 171semantics is identical - to the realloc C function). It is used to
84and free memory (no surprises here). If it returns zero when memory 172allocate and free memory (no surprises here). If it returns zero when
85needs to be allocated, the library might abort or take some potentially 173memory needs to be allocated, the library might abort or take some
86destructive action. The default is your system realloc function. 174potentially destructive action. The default is your system realloc
175function.
87 176
88You could override this function in high-availability programs to, say, 177You could override this function in high-availability programs to, say,
89free some memory if it cannot allocate memory, to use a special allocator, 178free some memory if it cannot allocate memory, to use a special allocator,
90or even to sleep a while and retry until some memory is available. 179or even to sleep a while and retry until some memory is available.
180
181Example: Replace the libev allocator with one that waits a bit and then
182retries).
183
184 static void *
185 persistent_realloc (void *ptr, size_t size)
186 {
187 for (;;)
188 {
189 void *newptr = realloc (ptr, size);
190
191 if (newptr)
192 return newptr;
193
194 sleep (60);
195 }
196 }
197
198 ...
199 ev_set_allocator (persistent_realloc);
91 200
92=item ev_set_syserr_cb (void (*cb)(const char *msg)); 201=item ev_set_syserr_cb (void (*cb)(const char *msg));
93 202
94Set the callback function to call on a retryable syscall error (such 203Set the callback function to call on a retryable syscall error (such
95as failed select, poll, epoll_wait). The message is a printable string 204as failed select, poll, epoll_wait). The message is a printable string
97callback is set, then libev will expect it to remedy the sitution, no 206callback is set, then libev will expect it to remedy the sitution, no
98matter what, when it returns. That is, libev will generally retry the 207matter what, when it returns. That is, libev will generally retry the
99requested operation, or, if the condition doesn't go away, do bad stuff 208requested operation, or, if the condition doesn't go away, do bad stuff
100(such as abort). 209(such as abort).
101 210
211Example: This is basically the same thing that libev does internally, too.
212
213 static void
214 fatal_error (const char *msg)
215 {
216 perror (msg);
217 abort ();
218 }
219
220 ...
221 ev_set_syserr_cb (fatal_error);
222
102=back 223=back
103 224
104=head1 FUNCTIONS CONTROLLING THE EVENT LOOP 225=head1 FUNCTIONS CONTROLLING THE EVENT LOOP
105 226
106An event loop is described by a C<struct ev_loop *>. The library knows two 227An event loop is described by a C<struct ev_loop *>. The library knows two
119=item struct ev_loop *ev_default_loop (unsigned int flags) 240=item struct ev_loop *ev_default_loop (unsigned int flags)
120 241
121This will initialise the default event loop if it hasn't been initialised 242This will initialise the default event loop if it hasn't been initialised
122yet and return it. If the default loop could not be initialised, returns 243yet and return it. If the default loop could not be initialised, returns
123false. If it already was initialised it simply returns it (and ignores the 244false. If it already was initialised it simply returns it (and ignores the
124flags). 245flags. If that is troubling you, check C<ev_backend ()> afterwards).
125 246
126If you don't know what event loop to use, use the one returned from this 247If you don't know what event loop to use, use the one returned from this
127function. 248function.
128 249
129The flags argument can be used to specify special behaviour or specific 250The flags argument can be used to specify special behaviour or specific
130backends to use, and is usually specified as 0 (or EVFLAG_AUTO). 251backends to use, and is usually specified as C<0> (or C<EVFLAG_AUTO>).
131 252
132It supports the following flags: 253The following flags are supported:
133 254
134=over 4 255=over 4
135 256
136=item C<EVFLAG_AUTO> 257=item C<EVFLAG_AUTO>
137 258
145C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will 266C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will
146override the flags completely if it is found in the environment. This is 267override the flags completely if it is found in the environment. This is
147useful to try out specific backends to test their performance, or to work 268useful to try out specific backends to test their performance, or to work
148around bugs. 269around bugs.
149 270
150=item C<EVMETHOD_SELECT> (value 1, portable select backend) 271=item C<EVBACKEND_SELECT> (value 1, portable select backend)
151 272
152This is your standard select(2) backend. Not I<completely> standard, as 273This is your standard select(2) backend. Not I<completely> standard, as
153libev tries to roll its own fd_set with no limits on the number of fds, 274libev tries to roll its own fd_set with no limits on the number of fds,
154but if that fails, expect a fairly low limit on the number of fds when 275but if that fails, expect a fairly low limit on the number of fds when
155using this backend. It doesn't scale too well (O(highest_fd)), but its usually 276using this backend. It doesn't scale too well (O(highest_fd)), but its usually
156the fastest backend for a low number of fds. 277the fastest backend for a low number of fds.
157 278
158=item C<EVMETHOD_POLL> (value 2, poll backend, available everywhere except on windows) 279=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
159 280
160And this is your standard poll(2) backend. It's more complicated than 281And this is your standard poll(2) backend. It's more complicated than
161select, but handles sparse fds better and has no artificial limit on the 282select, but handles sparse fds better and has no artificial limit on the
162number of fds you can use (except it will slow down considerably with a 283number of fds you can use (except it will slow down considerably with a
163lot of inactive fds). It scales similarly to select, i.e. O(total_fds). 284lot of inactive fds). It scales similarly to select, i.e. O(total_fds).
164 285
165=item C<EVMETHOD_EPOLL> (value 4, Linux) 286=item C<EVBACKEND_EPOLL> (value 4, Linux)
166 287
167For few fds, this backend is a bit little slower than poll and select, 288For few fds, this backend is a bit little slower than poll and select,
168but it scales phenomenally better. While poll and select usually scale like 289but it scales phenomenally better. While poll and select usually scale like
169O(total_fds) where n is the total number of fds (or the highest fd), epoll scales 290O(total_fds) where n is the total number of fds (or the highest fd), epoll scales
170either O(1) or O(active_fds). 291either O(1) or O(active_fds).
173result in some caching, there is still a syscall per such incident 294result in some caching, there is still a syscall per such incident
174(because the fd could point to a different file description now), so its 295(because the fd could point to a different file description now), so its
175best to avoid that. Also, dup()ed file descriptors might not work very 296best to avoid that. Also, dup()ed file descriptors might not work very
176well if you register events for both fds. 297well if you register events for both fds.
177 298
299Please note that epoll sometimes generates spurious notifications, so you
300need to use non-blocking I/O or other means to avoid blocking when no data
301(or space) is available.
302
178=item C<EVMETHOD_KQUEUE> (value 8, most BSD clones) 303=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
179 304
180Kqueue deserves special mention, as at the time of this writing, it 305Kqueue deserves special mention, as at the time of this writing, it
181was broken on all BSDs except NetBSD (usually it doesn't work with 306was broken on all BSDs except NetBSD (usually it doesn't work with
182anything but sockets and pipes, except on Darwin, where of course its 307anything but sockets and pipes, except on Darwin, where of course its
183completely useless). For this reason its not being "autodetected" unless 308completely useless). For this reason its not being "autodetected"
184you explicitly specify the flags (i.e. you don't use EVFLAG_AUTO). 309unless you explicitly specify it explicitly in the flags (i.e. using
310C<EVBACKEND_KQUEUE>).
185 311
186It scales in the same way as the epoll backend, but the interface to the 312It scales in the same way as the epoll backend, but the interface to the
187kernel is more efficient (which says nothing about its actual speed, of 313kernel is more efficient (which says nothing about its actual speed, of
188course). While starting and stopping an I/O watcher does not cause an 314course). While starting and stopping an I/O watcher does not cause an
189extra syscall as with epoll, it still adds up to four event changes per 315extra syscall as with epoll, it still adds up to four event changes per
190incident, so its best to avoid that. 316incident, so its best to avoid that.
191 317
192=item C<EVMETHOD_DEVPOLL> (value 16, Solaris 8) 318=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
193 319
194This is not implemented yet (and might never be). 320This is not implemented yet (and might never be).
195 321
196=item C<EVMETHOD_PORT> (value 32, Solaris 10) 322=item C<EVBACKEND_PORT> (value 32, Solaris 10)
197 323
198This uses the Solaris 10 port mechanism. As with everything on Solaris, 324This uses the Solaris 10 port mechanism. As with everything on Solaris,
199it's really slow, but it still scales very well (O(active_fds)). 325it's really slow, but it still scales very well (O(active_fds)).
200 326
327Please note that solaris ports can result in a lot of spurious
328notifications, so you need to use non-blocking I/O or other means to avoid
329blocking when no data (or space) is available.
330
201=item C<EVMETHOD_ALL> 331=item C<EVBACKEND_ALL>
202 332
203Try all backends (even potentially broken ones that wouldn't be tried 333Try all backends (even potentially broken ones that wouldn't be tried
204with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as 334with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as
205C<EVMETHOD_ALL & ~EVMETHOD_KQUEUE>. 335C<EVBACKEND_ALL & ~EVBACKEND_KQUEUE>.
206 336
207=back 337=back
208 338
209If one or more of these are ored into the flags value, then only these 339If one or more of these are ored into the flags value, then only these
210backends will be tried (in the reverse order as given here). If none are 340backends will be tried (in the reverse order as given here). If none are
211specified, most compiled-in backend will be tried, usually in reverse 341specified, most compiled-in backend will be tried, usually in reverse
212order of their flag values :) 342order of their flag values :)
213 343
344The most typical usage is like this:
345
346 if (!ev_default_loop (0))
347 fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
348
349Restrict libev to the select and poll backends, and do not allow
350environment settings to be taken into account:
351
352 ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
353
354Use whatever libev has to offer, but make sure that kqueue is used if
355available (warning, breaks stuff, best use only with your own private
356event loop and only if you know the OS supports your types of fds):
357
358 ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
359
214=item struct ev_loop *ev_loop_new (unsigned int flags) 360=item struct ev_loop *ev_loop_new (unsigned int flags)
215 361
216Similar to C<ev_default_loop>, but always creates a new event loop that is 362Similar to C<ev_default_loop>, but always creates a new event loop that is
217always distinct from the default loop. Unlike the default loop, it cannot 363always distinct from the default loop. Unlike the default loop, it cannot
218handle signal and child watchers, and attempts to do so will be greeted by 364handle signal and child watchers, and attempts to do so will be greeted by
219undefined behaviour (or a failed assertion if assertions are enabled). 365undefined behaviour (or a failed assertion if assertions are enabled).
220 366
367Example: Try to create a event loop that uses epoll and nothing else.
368
369 struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV);
370 if (!epoller)
371 fatal ("no epoll found here, maybe it hides under your chair");
372
221=item ev_default_destroy () 373=item ev_default_destroy ()
222 374
223Destroys the default loop again (frees all memory and kernel state 375Destroys the default loop again (frees all memory and kernel state
224etc.). This stops all registered event watchers (by not touching them in 376etc.). None of the active event watchers will be stopped in the normal
225any way whatsoever, although you cannot rely on this :). 377sense, so e.g. C<ev_is_active> might still return true. It is your
378responsibility to either stop all watchers cleanly yoursef I<before>
379calling this function, or cope with the fact afterwards (which is usually
380the easiest thing, youc na just ignore the watchers and/or C<free ()> them
381for example).
226 382
227=item ev_loop_destroy (loop) 383=item ev_loop_destroy (loop)
228 384
229Like C<ev_default_destroy>, but destroys an event loop created by an 385Like C<ev_default_destroy>, but destroys an event loop created by an
230earlier call to C<ev_loop_new>. 386earlier call to C<ev_loop_new>.
244it just in case after a fork. To make this easy, the function will fit in 400it just in case after a fork. To make this easy, the function will fit in
245quite nicely into a call to C<pthread_atfork>: 401quite nicely into a call to C<pthread_atfork>:
246 402
247 pthread_atfork (0, 0, ev_default_fork); 403 pthread_atfork (0, 0, ev_default_fork);
248 404
405At the moment, C<EVBACKEND_SELECT> and C<EVBACKEND_POLL> are safe to use
406without calling this function, so if you force one of those backends you
407do not need to care.
408
249=item ev_loop_fork (loop) 409=item ev_loop_fork (loop)
250 410
251Like C<ev_default_fork>, but acts on an event loop created by 411Like C<ev_default_fork>, but acts on an event loop created by
252C<ev_loop_new>. Yes, you have to call this on every allocated event loop 412C<ev_loop_new>. Yes, you have to call this on every allocated event loop
253after fork, and how you do this is entirely your own problem. 413after fork, and how you do this is entirely your own problem.
254 414
255=item unsigned int ev_method (loop) 415=item unsigned int ev_backend (loop)
256 416
257Returns one of the C<EVMETHOD_*> flags indicating the event backend in 417Returns one of the C<EVBACKEND_*> flags indicating the event backend in
258use. 418use.
259 419
260=item ev_tstamp ev_now (loop) 420=item ev_tstamp ev_now (loop)
261 421
262Returns the current "event loop time", which is the time the event loop 422Returns the current "event loop time", which is the time the event loop
263got events and started processing them. This timestamp does not change 423received events and started processing them. This timestamp does not
264as long as callbacks are being processed, and this is also the base time 424change as long as callbacks are being processed, and this is also the base
265used for relative timers. You can treat it as the timestamp of the event 425time used for relative timers. You can treat it as the timestamp of the
266occuring (or more correctly, the mainloop finding out about it). 426event occuring (or more correctly, libev finding out about it).
267 427
268=item ev_loop (loop, int flags) 428=item ev_loop (loop, int flags)
269 429
270Finally, this is it, the event handler. This function usually is called 430Finally, this is it, the event handler. This function usually is called
271after you initialised all your watchers and you want to start handling 431after you initialised all your watchers and you want to start handling
272events. 432events.
273 433
274If the flags argument is specified as 0, it will not return until either 434If the flags argument is specified as C<0>, it will not return until
275no event watchers are active anymore or C<ev_unloop> was called. 435either no event watchers are active anymore or C<ev_unloop> was called.
436
437Please note that an explicit C<ev_unloop> is usually better than
438relying on all watchers to be stopped when deciding when a program has
439finished (especially in interactive programs), but having a program that
440automatically loops as long as it has to and no longer by virtue of
441relying on its watchers stopping correctly is a thing of beauty.
276 442
277A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle 443A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle
278those events and any outstanding ones, but will not block your process in 444those events and any outstanding ones, but will not block your process in
279case there are no events and will return after one iteration of the loop. 445case there are no events and will return after one iteration of the loop.
280 446
281A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if 447A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if
282neccessary) and will handle those and any outstanding ones. It will block 448neccessary) and will handle those and any outstanding ones. It will block
283your process until at least one new event arrives, and will return after 449your process until at least one new event arrives, and will return after
284one iteration of the loop. 450one iteration of the loop. This is useful if you are waiting for some
451external event in conjunction with something not expressible using other
452libev watchers. However, a pair of C<ev_prepare>/C<ev_check> watchers is
453usually a better approach for this kind of thing.
285 454
286This flags value could be used to implement alternative looping
287constructs, but the C<prepare> and C<check> watchers provide a better and
288more generic mechanism.
289
290Here are the gory details of what ev_loop does: 455Here are the gory details of what C<ev_loop> does:
291 456
292 1. If there are no active watchers (reference count is zero), return. 457 * If there are no active watchers (reference count is zero), return.
293 2. Queue and immediately call all prepare watchers. 458 - Queue prepare watchers and then call all outstanding watchers.
294 3. If we have been forked, recreate the kernel state. 459 - If we have been forked, recreate the kernel state.
295 4. Update the kernel state with all outstanding changes. 460 - Update the kernel state with all outstanding changes.
296 5. Update the "event loop time". 461 - Update the "event loop time".
297 6. Calculate for how long to block. 462 - Calculate for how long to block.
298 7. Block the process, waiting for events. 463 - Block the process, waiting for any events.
464 - Queue all outstanding I/O (fd) events.
299 8. Update the "event loop time" and do time jump handling. 465 - Update the "event loop time" and do time jump handling.
300 9. Queue all outstanding timers. 466 - Queue all outstanding timers.
301 10. Queue all outstanding periodics. 467 - Queue all outstanding periodics.
302 11. If no events are pending now, queue all idle watchers. 468 - If no events are pending now, queue all idle watchers.
303 12. Queue all check watchers. 469 - Queue all check watchers.
304 13. Call all queued watchers in reverse order (i.e. check watchers first). 470 - Call all queued watchers in reverse order (i.e. check watchers first).
471 Signals and child watchers are implemented as I/O watchers, and will
472 be handled here by queueing them when their watcher gets executed.
305 14. If ev_unloop has been called or EVLOOP_ONESHOT or EVLOOP_NONBLOCK 473 - If ev_unloop has been called or EVLOOP_ONESHOT or EVLOOP_NONBLOCK
306 was used, return, otherwise continue with step #1. 474 were used, return, otherwise continue with step *.
475
476Example: Queue some jobs and then loop until no events are outsanding
477anymore.
478
479 ... queue jobs here, make sure they register event watchers as long
480 ... as they still have work to do (even an idle watcher will do..)
481 ev_loop (my_loop, 0);
482 ... jobs done. yeah!
307 483
308=item ev_unloop (loop, how) 484=item ev_unloop (loop, how)
309 485
310Can be used to make a call to C<ev_loop> return early (but only after it 486Can be used to make a call to C<ev_loop> return early (but only after it
311has processed all outstanding events). The C<how> argument must be either 487has processed all outstanding events). The C<how> argument must be either
325visible to the libev user and should not keep C<ev_loop> from exiting if 501visible to the libev user and should not keep C<ev_loop> from exiting if
326no event watchers registered by it are active. It is also an excellent 502no event watchers registered by it are active. It is also an excellent
327way to do this for generic recurring timers or from within third-party 503way to do this for generic recurring timers or from within third-party
328libraries. Just remember to I<unref after start> and I<ref before stop>. 504libraries. Just remember to I<unref after start> and I<ref before stop>.
329 505
506Example: Create a signal watcher, but keep it from keeping C<ev_loop>
507running when nothing else is active.
508
509 struct ev_signal exitsig;
510 ev_signal_init (&exitsig, sig_cb, SIGINT);
511 ev_signal_start (loop, &exitsig);
512 evf_unref (loop);
513
514Example: For some weird reason, unregister the above signal handler again.
515
516 ev_ref (loop);
517 ev_signal_stop (loop, &exitsig);
518
330=back 519=back
520
331 521
332=head1 ANATOMY OF A WATCHER 522=head1 ANATOMY OF A WATCHER
333 523
334A watcher is a structure that you create and register to record your 524A watcher is a structure that you create and register to record your
335interest in some event. For instance, if you want to wait for STDIN to 525interest in some event. For instance, if you want to wait for STDIN to
368*) >>), and you can stop watching for events at any time by calling the 558*) >>), and you can stop watching for events at any time by calling the
369corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>. 559corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>.
370 560
371As long as your watcher is active (has been started but not stopped) you 561As long as your watcher is active (has been started but not stopped) you
372must not touch the values stored in it. Most specifically you must never 562must not touch the values stored in it. Most specifically you must never
373reinitialise it or call its set method. 563reinitialise it or call its C<set> macro.
374
375You can check whether an event is active by calling the C<ev_is_active
376(watcher *)> macro. To see whether an event is outstanding (but the
377callback for it has not been called yet) you can use the C<ev_is_pending
378(watcher *)> macro.
379 564
380Each and every callback receives the event loop pointer as first, the 565Each and every callback receives the event loop pointer as first, the
381registered watcher structure as second, and a bitset of received events as 566registered watcher structure as second, and a bitset of received events as
382third argument. 567third argument.
383 568
407The signal specified in the C<ev_signal> watcher has been received by a thread. 592The signal specified in the C<ev_signal> watcher has been received by a thread.
408 593
409=item C<EV_CHILD> 594=item C<EV_CHILD>
410 595
411The pid specified in the C<ev_child> watcher has received a status change. 596The pid specified in the C<ev_child> watcher has received a status change.
597
598=item C<EV_STAT>
599
600The path specified in the C<ev_stat> watcher changed its attributes somehow.
412 601
413=item C<EV_IDLE> 602=item C<EV_IDLE>
414 603
415The C<ev_idle> watcher has determined that you have nothing better to do. 604The C<ev_idle> watcher has determined that you have nothing better to do.
416 605
424received events. Callbacks of both watcher types can start and stop as 613received events. Callbacks of both watcher types can start and stop as
425many watchers as they want, and all of them will be taken into account 614many watchers as they want, and all of them will be taken into account
426(for example, a C<ev_prepare> watcher might start an idle watcher to keep 615(for example, a C<ev_prepare> watcher might start an idle watcher to keep
427C<ev_loop> from blocking). 616C<ev_loop> from blocking).
428 617
618=item C<EV_EMBED>
619
620The embedded event loop specified in the C<ev_embed> watcher needs attention.
621
622=item C<EV_FORK>
623
624The event loop has been resumed in the child process after fork (see
625C<ev_fork>).
626
429=item C<EV_ERROR> 627=item C<EV_ERROR>
430 628
431An unspecified error has occured, the watcher has been stopped. This might 629An unspecified error has occured, the watcher has been stopped. This might
432happen because the watcher could not be properly started because libev 630happen because the watcher could not be properly started because libev
433ran out of memory, a file descriptor was found to be closed or any other 631ran out of memory, a file descriptor was found to be closed or any other
439your callbacks is well-written it can just attempt the operation and cope 637your callbacks is well-written it can just attempt the operation and cope
440with the error from read() or write(). This will not work in multithreaded 638with the error from read() or write(). This will not work in multithreaded
441programs, though, so beware. 639programs, though, so beware.
442 640
443=back 641=back
642
643=head2 GENERIC WATCHER FUNCTIONS
644
645In the following description, C<TYPE> stands for the watcher type,
646e.g. C<timer> for C<ev_timer> watchers and C<io> for C<ev_io> watchers.
647
648=over 4
649
650=item C<ev_init> (ev_TYPE *watcher, callback)
651
652This macro initialises the generic portion of a watcher. The contents
653of the watcher object can be arbitrary (so C<malloc> will do). Only
654the generic parts of the watcher are initialised, you I<need> to call
655the type-specific C<ev_TYPE_set> macro afterwards to initialise the
656type-specific parts. For each type there is also a C<ev_TYPE_init> macro
657which rolls both calls into one.
658
659You can reinitialise a watcher at any time as long as it has been stopped
660(or never started) and there are no pending events outstanding.
661
662The callback is always of type C<void (*)(ev_loop *loop, ev_TYPE *watcher,
663int revents)>.
664
665=item C<ev_TYPE_set> (ev_TYPE *, [args])
666
667This macro initialises the type-specific parts of a watcher. You need to
668call C<ev_init> at least once before you call this macro, but you can
669call C<ev_TYPE_set> any number of times. You must not, however, call this
670macro on a watcher that is active (it can be pending, however, which is a
671difference to the C<ev_init> macro).
672
673Although some watcher types do not have type-specific arguments
674(e.g. C<ev_prepare>) you still need to call its C<set> macro.
675
676=item C<ev_TYPE_init> (ev_TYPE *watcher, callback, [args])
677
678This convinience macro rolls both C<ev_init> and C<ev_TYPE_set> macro
679calls into a single call. This is the most convinient method to initialise
680a watcher. The same limitations apply, of course.
681
682=item C<ev_TYPE_start> (loop *, ev_TYPE *watcher)
683
684Starts (activates) the given watcher. Only active watchers will receive
685events. If the watcher is already active nothing will happen.
686
687=item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher)
688
689Stops the given watcher again (if active) and clears the pending
690status. It is possible that stopped watchers are pending (for example,
691non-repeating timers are being stopped when they become pending), but
692C<ev_TYPE_stop> ensures that the watcher is neither active nor pending. If
693you want to free or reuse the memory used by the watcher it is therefore a
694good idea to always call its C<ev_TYPE_stop> function.
695
696=item bool ev_is_active (ev_TYPE *watcher)
697
698Returns a true value iff the watcher is active (i.e. it has been started
699and not yet been stopped). As long as a watcher is active you must not modify
700it.
701
702=item bool ev_is_pending (ev_TYPE *watcher)
703
704Returns a true value iff the watcher is pending, (i.e. it has outstanding
705events but its callback has not yet been invoked). As long as a watcher
706is pending (but not active) you must not call an init function on it (but
707C<ev_TYPE_set> is safe) and you must make sure the watcher is available to
708libev (e.g. you cnanot C<free ()> it).
709
710=item callback ev_cb (ev_TYPE *watcher)
711
712Returns the callback currently set on the watcher.
713
714=item ev_cb_set (ev_TYPE *watcher, callback)
715
716Change the callback. You can change the callback at virtually any time
717(modulo threads).
718
719=back
720
444 721
445=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER 722=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
446 723
447Each watcher has, by default, a member C<void *data> that you can change 724Each watcher has, by default, a member C<void *data> that you can change
448and read at any time, libev will completely ignore it. This can be used 725and read at any time, libev will completely ignore it. This can be used
466 { 743 {
467 struct my_io *w = (struct my_io *)w_; 744 struct my_io *w = (struct my_io *)w_;
468 ... 745 ...
469 } 746 }
470 747
471More interesting and less C-conformant ways of catsing your callback type 748More interesting and less C-conformant ways of casting your callback type
472have been omitted.... 749instead have been omitted.
750
751Another common scenario is having some data structure with multiple
752watchers:
753
754 struct my_biggy
755 {
756 int some_data;
757 ev_timer t1;
758 ev_timer t2;
759 }
760
761In this case getting the pointer to C<my_biggy> is a bit more complicated,
762you need to use C<offsetof>:
763
764 #include <stddef.h>
765
766 static void
767 t1_cb (EV_P_ struct ev_timer *w, int revents)
768 {
769 struct my_biggy big = (struct my_biggy *
770 (((char *)w) - offsetof (struct my_biggy, t1));
771 }
772
773 static void
774 t2_cb (EV_P_ struct ev_timer *w, int revents)
775 {
776 struct my_biggy big = (struct my_biggy *
777 (((char *)w) - offsetof (struct my_biggy, t2));
778 }
473 779
474 780
475=head1 WATCHER TYPES 781=head1 WATCHER TYPES
476 782
477This section describes each watcher in detail, but will not repeat 783This section describes each watcher in detail, but will not repeat
478information given in the last section. 784information given in the last section. Any initialisation/set macros,
785functions and members specific to the watcher type are explained.
479 786
787Members are additionally marked with either I<[read-only]>, meaning that,
788while the watcher is active, you can look at the member and expect some
789sensible content, but you must not modify it (you can modify it while the
790watcher is stopped to your hearts content), or I<[read-write]>, which
791means you can expect it to have some sensible content while the watcher
792is active, but you can also modify it. Modifying it may not do something
793sensible or take immediate effect (or do anything at all), but libev will
794not crash or malfunction in any way.
795
796
480=head2 C<ev_io> - is this file descriptor readable or writable 797=head2 C<ev_io> - is this file descriptor readable or writable?
481 798
482I/O watchers check whether a file descriptor is readable or writable 799I/O watchers check whether a file descriptor is readable or writable
483in each iteration of the event loop (This behaviour is called 800in each iteration of the event loop, or, more precisely, when reading
484level-triggering because you keep receiving events as long as the 801would not block the process and writing would at least be able to write
485condition persists. Remember you can stop the watcher if you don't want to 802some data. This behaviour is called level-triggering because you keep
486act on the event and neither want to receive future events). 803receiving events as long as the condition persists. Remember you can stop
804the watcher if you don't want to act on the event and neither want to
805receive future events.
487 806
488In general you can register as many read and/or write event watchers per 807In general you can register as many read and/or write event watchers per
489fd as you want (as long as you don't confuse yourself). Setting all file 808fd as you want (as long as you don't confuse yourself). Setting all file
490descriptors to non-blocking mode is also usually a good idea (but not 809descriptors to non-blocking mode is also usually a good idea (but not
491required if you know what you are doing). 810required if you know what you are doing).
492 811
493You have to be careful with dup'ed file descriptors, though. Some backends 812You have to be careful with dup'ed file descriptors, though. Some backends
494(the linux epoll backend is a notable example) cannot handle dup'ed file 813(the linux epoll backend is a notable example) cannot handle dup'ed file
495descriptors correctly if you register interest in two or more fds pointing 814descriptors correctly if you register interest in two or more fds pointing
496to the same underlying file/socket etc. description (that is, they share 815to the same underlying file/socket/etc. description (that is, they share
497the same underlying "file open"). 816the same underlying "file open").
498 817
499If you must do this, then force the use of a known-to-be-good backend 818If you must do this, then force the use of a known-to-be-good backend
500(at the time of this writing, this includes only EVMETHOD_SELECT and 819(at the time of this writing, this includes only C<EVBACKEND_SELECT> and
501EVMETHOD_POLL). 820C<EVBACKEND_POLL>).
821
822Another thing you have to watch out for is that it is quite easy to
823receive "spurious" readyness notifications, that is your callback might
824be called with C<EV_READ> but a subsequent C<read>(2) will actually block
825because there is no data. Not only are some backends known to create a
826lot of those (for example solaris ports), it is very easy to get into
827this situation even with a relatively standard program structure. Thus
828it is best to always use non-blocking I/O: An extra C<read>(2) returning
829C<EAGAIN> is far preferable to a program hanging until some data arrives.
830
831If you cannot run the fd in non-blocking mode (for example you should not
832play around with an Xlib connection), then you have to seperately re-test
833wether a file descriptor is really ready with a known-to-be good interface
834such as poll (fortunately in our Xlib example, Xlib already does this on
835its own, so its quite safe to use).
502 836
503=over 4 837=over 4
504 838
505=item ev_io_init (ev_io *, callback, int fd, int events) 839=item ev_io_init (ev_io *, callback, int fd, int events)
506 840
507=item ev_io_set (ev_io *, int fd, int events) 841=item ev_io_set (ev_io *, int fd, int events)
508 842
509Configures an C<ev_io> watcher. The fd is the file descriptor to rceeive 843Configures an C<ev_io> watcher. The C<fd> is the file descriptor to
510events for and events is either C<EV_READ>, C<EV_WRITE> or C<EV_READ | 844rceeive events for and events is either C<EV_READ>, C<EV_WRITE> or
511EV_WRITE> to receive the given events. 845C<EV_READ | EV_WRITE> to receive the given events.
846
847=item int fd [read-only]
848
849The file descriptor being watched.
850
851=item int events [read-only]
852
853The events being watched.
512 854
513=back 855=back
514 856
857Example: Call C<stdin_readable_cb> when STDIN_FILENO has become, well
858readable, but only once. Since it is likely line-buffered, you could
859attempt to read a whole line in the callback.
860
861 static void
862 stdin_readable_cb (struct ev_loop *loop, struct ev_io *w, int revents)
863 {
864 ev_io_stop (loop, w);
865 .. read from stdin here (or from w->fd) and haqndle any I/O errors
866 }
867
868 ...
869 struct ev_loop *loop = ev_default_init (0);
870 struct ev_io stdin_readable;
871 ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ);
872 ev_io_start (loop, &stdin_readable);
873 ev_loop (loop, 0);
874
875
515=head2 C<ev_timer> - relative and optionally recurring timeouts 876=head2 C<ev_timer> - relative and optionally repeating timeouts
516 877
517Timer watchers are simple relative timers that generate an event after a 878Timer watchers are simple relative timers that generate an event after a
518given time, and optionally repeating in regular intervals after that. 879given time, and optionally repeating in regular intervals after that.
519 880
520The timers are based on real time, that is, if you register an event that 881The timers are based on real time, that is, if you register an event that
561 922
562If the timer is repeating, either start it if necessary (with the repeat 923If the timer is repeating, either start it if necessary (with the repeat
563value), or reset the running timer to the repeat value. 924value), or reset the running timer to the repeat value.
564 925
565This sounds a bit complicated, but here is a useful and typical 926This sounds a bit complicated, but here is a useful and typical
566example: Imagine you have a tcp connection and you want a so-called idle 927example: Imagine you have a tcp connection and you want a so-called
567timeout, that is, you want to be called when there have been, say, 60 928idle timeout, that is, you want to be called when there have been,
568seconds of inactivity on the socket. The easiest way to do this is to 929say, 60 seconds of inactivity on the socket. The easiest way to do
569configure an C<ev_timer> with after=repeat=60 and calling ev_timer_again each 930this is to configure an C<ev_timer> with C<after>=C<repeat>=C<60> and calling
570time you successfully read or write some data. If you go into an idle 931C<ev_timer_again> each time you successfully read or write some data. If
571state where you do not expect data to travel on the socket, you can stop 932you go into an idle state where you do not expect data to travel on the
572the timer, and again will automatically restart it if need be. 933socket, you can stop the timer, and again will automatically restart it if
934need be.
935
936You can also ignore the C<after> value and C<ev_timer_start> altogether
937and only ever use the C<repeat> value:
938
939 ev_timer_init (timer, callback, 0., 5.);
940 ev_timer_again (loop, timer);
941 ...
942 timer->again = 17.;
943 ev_timer_again (loop, timer);
944 ...
945 timer->again = 10.;
946 ev_timer_again (loop, timer);
947
948This is more efficient then stopping/starting the timer eahc time you want
949to modify its timeout value.
950
951=item ev_tstamp repeat [read-write]
952
953The current C<repeat> value. Will be used each time the watcher times out
954or C<ev_timer_again> is called and determines the next timeout (if any),
955which is also when any modifications are taken into account.
573 956
574=back 957=back
575 958
959Example: Create a timer that fires after 60 seconds.
960
961 static void
962 one_minute_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
963 {
964 .. one minute over, w is actually stopped right here
965 }
966
967 struct ev_timer mytimer;
968 ev_timer_init (&mytimer, one_minute_cb, 60., 0.);
969 ev_timer_start (loop, &mytimer);
970
971Example: Create a timeout timer that times out after 10 seconds of
972inactivity.
973
974 static void
975 timeout_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
976 {
977 .. ten seconds without any activity
978 }
979
980 struct ev_timer mytimer;
981 ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */
982 ev_timer_again (&mytimer); /* start timer */
983 ev_loop (loop, 0);
984
985 // and in some piece of code that gets executed on any "activity":
986 // reset the timeout to start ticking again at 10 seconds
987 ev_timer_again (&mytimer);
988
989
576=head2 C<ev_periodic> - to cron or not to cron 990=head2 C<ev_periodic> - to cron or not to cron?
577 991
578Periodic watchers are also timers of a kind, but they are very versatile 992Periodic watchers are also timers of a kind, but they are very versatile
579(and unfortunately a bit complex). 993(and unfortunately a bit complex).
580 994
581Unlike C<ev_timer>'s, they are not based on real time (or relative time) 995Unlike C<ev_timer>'s, they are not based on real time (or relative time)
582but on wallclock time (absolute time). You can tell a periodic watcher 996but on wallclock time (absolute time). You can tell a periodic watcher
583to trigger "at" some specific point in time. For example, if you tell a 997to trigger "at" some specific point in time. For example, if you tell a
584periodic watcher to trigger in 10 seconds (by specifiying e.g. c<ev_now () 998periodic watcher to trigger in 10 seconds (by specifiying e.g. C<ev_now ()
585+ 10.>) and then reset your system clock to the last year, then it will 999+ 10.>) and then reset your system clock to the last year, then it will
586take a year to trigger the event (unlike an C<ev_timer>, which would trigger 1000take a year to trigger the event (unlike an C<ev_timer>, which would trigger
587roughly 10 seconds later and of course not if you reset your system time 1001roughly 10 seconds later and of course not if you reset your system time
588again). 1002again).
589 1003
673Simply stops and restarts the periodic watcher again. This is only useful 1087Simply stops and restarts the periodic watcher again. This is only useful
674when you changed some parameters or the reschedule callback would return 1088when you changed some parameters or the reschedule callback would return
675a different time than the last time it was called (e.g. in a crond like 1089a different time than the last time it was called (e.g. in a crond like
676program when the crontabs have changed). 1090program when the crontabs have changed).
677 1091
1092=item ev_tstamp interval [read-write]
1093
1094The current interval value. Can be modified any time, but changes only
1095take effect when the periodic timer fires or C<ev_periodic_again> is being
1096called.
1097
1098=item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write]
1099
1100The current reschedule callback, or C<0>, if this functionality is
1101switched off. Can be changed any time, but changes only take effect when
1102the periodic timer fires or C<ev_periodic_again> is being called.
1103
678=back 1104=back
679 1105
1106Example: Call a callback every hour, or, more precisely, whenever the
1107system clock is divisible by 3600. The callback invocation times have
1108potentially a lot of jittering, but good long-term stability.
1109
1110 static void
1111 clock_cb (struct ev_loop *loop, struct ev_io *w, int revents)
1112 {
1113 ... its now a full hour (UTC, or TAI or whatever your clock follows)
1114 }
1115
1116 struct ev_periodic hourly_tick;
1117 ev_periodic_init (&hourly_tick, clock_cb, 0., 3600., 0);
1118 ev_periodic_start (loop, &hourly_tick);
1119
1120Example: The same as above, but use a reschedule callback to do it:
1121
1122 #include <math.h>
1123
1124 static ev_tstamp
1125 my_scheduler_cb (struct ev_periodic *w, ev_tstamp now)
1126 {
1127 return fmod (now, 3600.) + 3600.;
1128 }
1129
1130 ev_periodic_init (&hourly_tick, clock_cb, 0., 0., my_scheduler_cb);
1131
1132Example: Call a callback every hour, starting now:
1133
1134 struct ev_periodic hourly_tick;
1135 ev_periodic_init (&hourly_tick, clock_cb,
1136 fmod (ev_now (loop), 3600.), 3600., 0);
1137 ev_periodic_start (loop, &hourly_tick);
1138
1139
680=head2 C<ev_signal> - signal me when a signal gets signalled 1140=head2 C<ev_signal> - signal me when a signal gets signalled!
681 1141
682Signal watchers will trigger an event when the process receives a specific 1142Signal watchers will trigger an event when the process receives a specific
683signal one or more times. Even though signals are very asynchronous, libev 1143signal one or more times. Even though signals are very asynchronous, libev
684will try it's best to deliver signals synchronously, i.e. as part of the 1144will try it's best to deliver signals synchronously, i.e. as part of the
685normal event processing, like any other event. 1145normal event processing, like any other event.
698=item ev_signal_set (ev_signal *, int signum) 1158=item ev_signal_set (ev_signal *, int signum)
699 1159
700Configures the watcher to trigger on the given signal number (usually one 1160Configures the watcher to trigger on the given signal number (usually one
701of the C<SIGxxx> constants). 1161of the C<SIGxxx> constants).
702 1162
1163=item int signum [read-only]
1164
1165The signal the watcher watches out for.
1166
703=back 1167=back
704 1168
1169
705=head2 C<ev_child> - wait for pid status changes 1170=head2 C<ev_child> - watch out for process status changes
706 1171
707Child watchers trigger when your process receives a SIGCHLD in response to 1172Child watchers trigger when your process receives a SIGCHLD in response to
708some child status changes (most typically when a child of yours dies). 1173some child status changes (most typically when a child of yours dies).
709 1174
710=over 4 1175=over 4
718at the C<rstatus> member of the C<ev_child> watcher structure to see 1183at the C<rstatus> member of the C<ev_child> watcher structure to see
719the status word (use the macros from C<sys/wait.h> and see your systems 1184the status word (use the macros from C<sys/wait.h> and see your systems
720C<waitpid> documentation). The C<rpid> member contains the pid of the 1185C<waitpid> documentation). The C<rpid> member contains the pid of the
721process causing the status change. 1186process causing the status change.
722 1187
1188=item int pid [read-only]
1189
1190The process id this watcher watches out for, or C<0>, meaning any process id.
1191
1192=item int rpid [read-write]
1193
1194The process id that detected a status change.
1195
1196=item int rstatus [read-write]
1197
1198The process exit/trace status caused by C<rpid> (see your systems
1199C<waitpid> and C<sys/wait.h> documentation for details).
1200
723=back 1201=back
724 1202
1203Example: Try to exit cleanly on SIGINT and SIGTERM.
1204
1205 static void
1206 sigint_cb (struct ev_loop *loop, struct ev_signal *w, int revents)
1207 {
1208 ev_unloop (loop, EVUNLOOP_ALL);
1209 }
1210
1211 struct ev_signal signal_watcher;
1212 ev_signal_init (&signal_watcher, sigint_cb, SIGINT);
1213 ev_signal_start (loop, &sigint_cb);
1214
1215
1216=head2 C<ev_stat> - did the file attributes just change?
1217
1218This watches a filesystem path for attribute changes. That is, it calls
1219C<stat> regularly (or when the OS says it changed) and sees if it changed
1220compared to the last time, invoking the callback if it did.
1221
1222The path does not need to exist: changing from "path exists" to "path does
1223not exist" is a status change like any other. The condition "path does
1224not exist" is signified by the C<st_nlink> field being zero (which is
1225otherwise always forced to be at least one) and all the other fields of
1226the stat buffer having unspecified contents.
1227
1228The path I<should> be absolute and I<must not> end in a slash. If it is
1229relative and your working directory changes, the behaviour is undefined.
1230
1231Since there is no standard to do this, the portable implementation simply
1232calls C<stat (2)> regularly on the path to see if it changed somehow. You
1233can specify a recommended polling interval for this case. If you specify
1234a polling interval of C<0> (highly recommended!) then a I<suitable,
1235unspecified default> value will be used (which you can expect to be around
1236five seconds, although this might change dynamically). Libev will also
1237impose a minimum interval which is currently around C<0.1>, but thats
1238usually overkill.
1239
1240This watcher type is not meant for massive numbers of stat watchers,
1241as even with OS-supported change notifications, this can be
1242resource-intensive.
1243
1244At the time of this writing, only the Linux inotify interface is
1245implemented (implementing kqueue support is left as an exercise for the
1246reader). Inotify will be used to give hints only and should not change the
1247semantics of C<ev_stat> watchers, which means that libev sometimes needs
1248to fall back to regular polling again even with inotify, but changes are
1249usually detected immediately, and if the file exists there will be no
1250polling.
1251
1252=over 4
1253
1254=item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)
1255
1256=item ev_stat_set (ev_stat *, const char *path, ev_tstamp interval)
1257
1258Configures the watcher to wait for status changes of the given
1259C<path>. The C<interval> is a hint on how quickly a change is expected to
1260be detected and should normally be specified as C<0> to let libev choose
1261a suitable value. The memory pointed to by C<path> must point to the same
1262path for as long as the watcher is active.
1263
1264The callback will be receive C<EV_STAT> when a change was detected,
1265relative to the attributes at the time the watcher was started (or the
1266last change was detected).
1267
1268=item ev_stat_stat (ev_stat *)
1269
1270Updates the stat buffer immediately with new values. If you change the
1271watched path in your callback, you could call this fucntion to avoid
1272detecting this change (while introducing a race condition). Can also be
1273useful simply to find out the new values.
1274
1275=item ev_statdata attr [read-only]
1276
1277The most-recently detected attributes of the file. Although the type is of
1278C<ev_statdata>, this is usually the (or one of the) C<struct stat> types
1279suitable for your system. If the C<st_nlink> member is C<0>, then there
1280was some error while C<stat>ing the file.
1281
1282=item ev_statdata prev [read-only]
1283
1284The previous attributes of the file. The callback gets invoked whenever
1285C<prev> != C<attr>.
1286
1287=item ev_tstamp interval [read-only]
1288
1289The specified interval.
1290
1291=item const char *path [read-only]
1292
1293The filesystem path that is being watched.
1294
1295=back
1296
1297Example: Watch C</etc/passwd> for attribute changes.
1298
1299 static void
1300 passwd_cb (struct ev_loop *loop, ev_stat *w, int revents)
1301 {
1302 /* /etc/passwd changed in some way */
1303 if (w->attr.st_nlink)
1304 {
1305 printf ("passwd current size %ld\n", (long)w->attr.st_size);
1306 printf ("passwd current atime %ld\n", (long)w->attr.st_mtime);
1307 printf ("passwd current mtime %ld\n", (long)w->attr.st_mtime);
1308 }
1309 else
1310 /* you shalt not abuse printf for puts */
1311 puts ("wow, /etc/passwd is not there, expect problems. "
1312 "if this is windows, they already arrived\n");
1313 }
1314
1315 ...
1316 ev_stat passwd;
1317
1318 ev_stat_init (&passwd, passwd_cb, "/etc/passwd");
1319 ev_stat_start (loop, &passwd);
1320
1321
725=head2 C<ev_idle> - when you've got nothing better to do 1322=head2 C<ev_idle> - when you've got nothing better to do...
726 1323
727Idle watchers trigger events when there are no other events are pending 1324Idle watchers trigger events when there are no other events are pending
728(prepare, check and other idle watchers do not count). That is, as long 1325(prepare, check and other idle watchers do not count). That is, as long
729as your process is busy handling sockets or timeouts (or even signals, 1326as your process is busy handling sockets or timeouts (or even signals,
730imagine) it will not be triggered. But when your process is idle all idle 1327imagine) it will not be triggered. But when your process is idle all idle
748kind. There is a C<ev_idle_set> macro, but using it is utterly pointless, 1345kind. There is a C<ev_idle_set> macro, but using it is utterly pointless,
749believe me. 1346believe me.
750 1347
751=back 1348=back
752 1349
1350Example: Dynamically allocate an C<ev_idle> watcher, start it, and in the
1351callback, free it. Also, use no error checking, as usual.
1352
1353 static void
1354 idle_cb (struct ev_loop *loop, struct ev_idle *w, int revents)
1355 {
1356 free (w);
1357 // now do something you wanted to do when the program has
1358 // no longer asnything immediate to do.
1359 }
1360
1361 struct ev_idle *idle_watcher = malloc (sizeof (struct ev_idle));
1362 ev_idle_init (idle_watcher, idle_cb);
1363 ev_idle_start (loop, idle_cb);
1364
1365
753=head2 C<ev_prepare> and C<ev_check> - customise your event loop 1366=head2 C<ev_prepare> and C<ev_check> - customise your event loop!
754 1367
755Prepare and check watchers are usually (but not always) used in tandem: 1368Prepare and check watchers are usually (but not always) used in tandem:
756prepare watchers get invoked before the process blocks and check watchers 1369prepare watchers get invoked before the process blocks and check watchers
757afterwards. 1370afterwards.
758 1371
1372You I<must not> call C<ev_loop> or similar functions that enter
1373the current event loop from either C<ev_prepare> or C<ev_check>
1374watchers. Other loops than the current one are fine, however. The
1375rationale behind this is that you do not need to check for recursion in
1376those watchers, i.e. the sequence will always be C<ev_prepare>, blocking,
1377C<ev_check> so if you have one watcher of each kind they will always be
1378called in pairs bracketing the blocking call.
1379
759Their main purpose is to integrate other event mechanisms into libev. This 1380Their main purpose is to integrate other event mechanisms into libev and
760could be used, for example, to track variable changes, implement your own 1381their use is somewhat advanced. This could be used, for example, to track
761watchers, integrate net-snmp or a coroutine library and lots more. 1382variable changes, implement your own watchers, integrate net-snmp or a
1383coroutine library and lots more. They are also occasionally useful if
1384you cache some data and want to flush it before blocking (for example,
1385in X programs you might want to do an C<XFlush ()> in an C<ev_prepare>
1386watcher).
762 1387
763This is done by examining in each prepare call which file descriptors need 1388This is done by examining in each prepare call which file descriptors need
764to be watched by the other library, registering C<ev_io> watchers for 1389to be watched by the other library, registering C<ev_io> watchers for
765them and starting an C<ev_timer> watcher for any timeouts (many libraries 1390them and starting an C<ev_timer> watcher for any timeouts (many libraries
766provide just this functionality). Then, in the check watcher you check for 1391provide just this functionality). Then, in the check watcher you check for
788parameters of any kind. There are C<ev_prepare_set> and C<ev_check_set> 1413parameters of any kind. There are C<ev_prepare_set> and C<ev_check_set>
789macros, but using them is utterly, utterly and completely pointless. 1414macros, but using them is utterly, utterly and completely pointless.
790 1415
791=back 1416=back
792 1417
1418Example: To include a library such as adns, you would add IO watchers
1419and a timeout watcher in a prepare handler, as required by libadns, and
1420in a check watcher, destroy them and call into libadns. What follows is
1421pseudo-code only of course:
1422
1423 static ev_io iow [nfd];
1424 static ev_timer tw;
1425
1426 static void
1427 io_cb (ev_loop *loop, ev_io *w, int revents)
1428 {
1429 // set the relevant poll flags
1430 // could also call adns_processreadable etc. here
1431 struct pollfd *fd = (struct pollfd *)w->data;
1432 if (revents & EV_READ ) fd->revents |= fd->events & POLLIN;
1433 if (revents & EV_WRITE) fd->revents |= fd->events & POLLOUT;
1434 }
1435
1436 // create io watchers for each fd and a timer before blocking
1437 static void
1438 adns_prepare_cb (ev_loop *loop, ev_prepare *w, int revents)
1439 {
1440 int timeout = 3600000;truct pollfd fds [nfd];
1441 // actual code will need to loop here and realloc etc.
1442 adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ()));
1443
1444 /* the callback is illegal, but won't be called as we stop during check */
1445 ev_timer_init (&tw, 0, timeout * 1e-3);
1446 ev_timer_start (loop, &tw);
1447
1448 // create on ev_io per pollfd
1449 for (int i = 0; i < nfd; ++i)
1450 {
1451 ev_io_init (iow + i, io_cb, fds [i].fd,
1452 ((fds [i].events & POLLIN ? EV_READ : 0)
1453 | (fds [i].events & POLLOUT ? EV_WRITE : 0)));
1454
1455 fds [i].revents = 0;
1456 iow [i].data = fds + i;
1457 ev_io_start (loop, iow + i);
1458 }
1459 }
1460
1461 // stop all watchers after blocking
1462 static void
1463 adns_check_cb (ev_loop *loop, ev_check *w, int revents)
1464 {
1465 ev_timer_stop (loop, &tw);
1466
1467 for (int i = 0; i < nfd; ++i)
1468 ev_io_stop (loop, iow + i);
1469
1470 adns_afterpoll (adns, fds, nfd, timeval_from (ev_now (loop));
1471 }
1472
1473
1474=head2 C<ev_embed> - when one backend isn't enough...
1475
1476This is a rather advanced watcher type that lets you embed one event loop
1477into another (currently only C<ev_io> events are supported in the embedded
1478loop, other types of watchers might be handled in a delayed or incorrect
1479fashion and must not be used).
1480
1481There are primarily two reasons you would want that: work around bugs and
1482prioritise I/O.
1483
1484As an example for a bug workaround, the kqueue backend might only support
1485sockets on some platform, so it is unusable as generic backend, but you
1486still want to make use of it because you have many sockets and it scales
1487so nicely. In this case, you would create a kqueue-based loop and embed it
1488into your default loop (which might use e.g. poll). Overall operation will
1489be a bit slower because first libev has to poll and then call kevent, but
1490at least you can use both at what they are best.
1491
1492As for prioritising I/O: rarely you have the case where some fds have
1493to be watched and handled very quickly (with low latency), and even
1494priorities and idle watchers might have too much overhead. In this case
1495you would put all the high priority stuff in one loop and all the rest in
1496a second one, and embed the second one in the first.
1497
1498As long as the watcher is active, the callback will be invoked every time
1499there might be events pending in the embedded loop. The callback must then
1500call C<ev_embed_sweep (mainloop, watcher)> to make a single sweep and invoke
1501their callbacks (you could also start an idle watcher to give the embedded
1502loop strictly lower priority for example). You can also set the callback
1503to C<0>, in which case the embed watcher will automatically execute the
1504embedded loop sweep.
1505
1506As long as the watcher is started it will automatically handle events. The
1507callback will be invoked whenever some events have been handled. You can
1508set the callback to C<0> to avoid having to specify one if you are not
1509interested in that.
1510
1511Also, there have not currently been made special provisions for forking:
1512when you fork, you not only have to call C<ev_loop_fork> on both loops,
1513but you will also have to stop and restart any C<ev_embed> watchers
1514yourself.
1515
1516Unfortunately, not all backends are embeddable, only the ones returned by
1517C<ev_embeddable_backends> are, which, unfortunately, does not include any
1518portable one.
1519
1520So when you want to use this feature you will always have to be prepared
1521that you cannot get an embeddable loop. The recommended way to get around
1522this is to have a separate variables for your embeddable loop, try to
1523create it, and if that fails, use the normal loop for everything:
1524
1525 struct ev_loop *loop_hi = ev_default_init (0);
1526 struct ev_loop *loop_lo = 0;
1527 struct ev_embed embed;
1528
1529 // see if there is a chance of getting one that works
1530 // (remember that a flags value of 0 means autodetection)
1531 loop_lo = ev_embeddable_backends () & ev_recommended_backends ()
1532 ? ev_loop_new (ev_embeddable_backends () & ev_recommended_backends ())
1533 : 0;
1534
1535 // if we got one, then embed it, otherwise default to loop_hi
1536 if (loop_lo)
1537 {
1538 ev_embed_init (&embed, 0, loop_lo);
1539 ev_embed_start (loop_hi, &embed);
1540 }
1541 else
1542 loop_lo = loop_hi;
1543
1544=over 4
1545
1546=item ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)
1547
1548=item ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)
1549
1550Configures the watcher to embed the given loop, which must be
1551embeddable. If the callback is C<0>, then C<ev_embed_sweep> will be
1552invoked automatically, otherwise it is the responsibility of the callback
1553to invoke it (it will continue to be called until the sweep has been done,
1554if you do not want thta, you need to temporarily stop the embed watcher).
1555
1556=item ev_embed_sweep (loop, ev_embed *)
1557
1558Make a single, non-blocking sweep over the embedded loop. This works
1559similarly to C<ev_loop (embedded_loop, EVLOOP_NONBLOCK)>, but in the most
1560apropriate way for embedded loops.
1561
1562=item struct ev_loop *loop [read-only]
1563
1564The embedded event loop.
1565
1566=back
1567
1568
1569=head2 C<ev_fork> - the audacity to resume the event loop after a fork
1570
1571Fork watchers are called when a C<fork ()> was detected (usually because
1572whoever is a good citizen cared to tell libev about it by calling
1573C<ev_default_fork> or C<ev_loop_fork>). The invocation is done before the
1574event loop blocks next and before C<ev_check> watchers are being called,
1575and only in the child after the fork. If whoever good citizen calling
1576C<ev_default_fork> cheats and calls it in the wrong process, the fork
1577handlers will be invoked, too, of course.
1578
1579=over 4
1580
1581=item ev_fork_init (ev_signal *, callback)
1582
1583Initialises and configures the fork watcher - it has no parameters of any
1584kind. There is a C<ev_fork_set> macro, but using it is utterly pointless,
1585believe me.
1586
1587=back
1588
1589
793=head1 OTHER FUNCTIONS 1590=head1 OTHER FUNCTIONS
794 1591
795There are some other functions of possible interest. Described. Here. Now. 1592There are some other functions of possible interest. Described. Here. Now.
796 1593
797=over 4 1594=over 4
826 /* stdin might have data for us, joy! */; 1623 /* stdin might have data for us, joy! */;
827 } 1624 }
828 1625
829 ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0); 1626 ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);
830 1627
831=item ev_feed_event (loop, watcher, int events) 1628=item ev_feed_event (ev_loop *, watcher *, int revents)
832 1629
833Feeds the given event set into the event loop, as if the specified event 1630Feeds the given event set into the event loop, as if the specified event
834had happened for the specified watcher (which must be a pointer to an 1631had happened for the specified watcher (which must be a pointer to an
835initialised but not necessarily started event watcher). 1632initialised but not necessarily started event watcher).
836 1633
837=item ev_feed_fd_event (loop, int fd, int revents) 1634=item ev_feed_fd_event (ev_loop *, int fd, int revents)
838 1635
839Feed an event on the given fd, as if a file descriptor backend detected 1636Feed an event on the given fd, as if a file descriptor backend detected
840the given events it. 1637the given events it.
841 1638
842=item ev_feed_signal_event (loop, int signum) 1639=item ev_feed_signal_event (ev_loop *loop, int signum)
843 1640
844Feed an event as if the given signal occured (loop must be the default loop!). 1641Feed an event as if the given signal occured (C<loop> must be the default
1642loop!).
845 1643
846=back 1644=back
1645
847 1646
848=head1 LIBEVENT EMULATION 1647=head1 LIBEVENT EMULATION
849 1648
850Libev offers a compatibility emulation layer for libevent. It cannot 1649Libev offers a compatibility emulation layer for libevent. It cannot
851emulate the internals of libevent, so here are some usage hints: 1650emulate the internals of libevent, so here are some usage hints:
872 1671
873=back 1672=back
874 1673
875=head1 C++ SUPPORT 1674=head1 C++ SUPPORT
876 1675
877TBD. 1676Libev comes with some simplistic wrapper classes for C++ that mainly allow
1677you to use some convinience methods to start/stop watchers and also change
1678the callback model to a model using method callbacks on objects.
1679
1680To use it,
1681
1682 #include <ev++.h>
1683
1684(it is not installed by default). This automatically includes F<ev.h>
1685and puts all of its definitions (many of them macros) into the global
1686namespace. All C++ specific things are put into the C<ev> namespace.
1687
1688It should support all the same embedding options as F<ev.h>, most notably
1689C<EV_MULTIPLICITY>.
1690
1691Here is a list of things available in the C<ev> namespace:
1692
1693=over 4
1694
1695=item C<ev::READ>, C<ev::WRITE> etc.
1696
1697These are just enum values with the same values as the C<EV_READ> etc.
1698macros from F<ev.h>.
1699
1700=item C<ev::tstamp>, C<ev::now>
1701
1702Aliases to the same types/functions as with the C<ev_> prefix.
1703
1704=item C<ev::io>, C<ev::timer>, C<ev::periodic>, C<ev::idle>, C<ev::sig> etc.
1705
1706For each C<ev_TYPE> watcher in F<ev.h> there is a corresponding class of
1707the same name in the C<ev> namespace, with the exception of C<ev_signal>
1708which is called C<ev::sig> to avoid clashes with the C<signal> macro
1709defines by many implementations.
1710
1711All of those classes have these methods:
1712
1713=over 4
1714
1715=item ev::TYPE::TYPE (object *, object::method *)
1716
1717=item ev::TYPE::TYPE (object *, object::method *, struct ev_loop *)
1718
1719=item ev::TYPE::~TYPE
1720
1721The constructor takes a pointer to an object and a method pointer to
1722the event handler callback to call in this class. The constructor calls
1723C<ev_init> for you, which means you have to call the C<set> method
1724before starting it. If you do not specify a loop then the constructor
1725automatically associates the default loop with this watcher.
1726
1727The destructor automatically stops the watcher if it is active.
1728
1729=item w->set (struct ev_loop *)
1730
1731Associates a different C<struct ev_loop> with this watcher. You can only
1732do this when the watcher is inactive (and not pending either).
1733
1734=item w->set ([args])
1735
1736Basically the same as C<ev_TYPE_set>, with the same args. Must be
1737called at least once. Unlike the C counterpart, an active watcher gets
1738automatically stopped and restarted.
1739
1740=item w->start ()
1741
1742Starts the watcher. Note that there is no C<loop> argument as the
1743constructor already takes the loop.
1744
1745=item w->stop ()
1746
1747Stops the watcher if it is active. Again, no C<loop> argument.
1748
1749=item w->again () C<ev::timer>, C<ev::periodic> only
1750
1751For C<ev::timer> and C<ev::periodic>, this invokes the corresponding
1752C<ev_TYPE_again> function.
1753
1754=item w->sweep () C<ev::embed> only
1755
1756Invokes C<ev_embed_sweep>.
1757
1758=item w->update () C<ev::stat> only
1759
1760Invokes C<ev_stat_stat>.
1761
1762=back
1763
1764=back
1765
1766Example: Define a class with an IO and idle watcher, start one of them in
1767the constructor.
1768
1769 class myclass
1770 {
1771 ev_io io; void io_cb (ev::io &w, int revents);
1772 ev_idle idle void idle_cb (ev::idle &w, int revents);
1773
1774 myclass ();
1775 }
1776
1777 myclass::myclass (int fd)
1778 : io (this, &myclass::io_cb),
1779 idle (this, &myclass::idle_cb)
1780 {
1781 io.start (fd, ev::READ);
1782 }
1783
1784
1785=head1 MACRO MAGIC
1786
1787Libev can be compiled with a variety of options, the most fundemantal is
1788C<EV_MULTIPLICITY>. This option determines wether (most) functions and
1789callbacks have an initial C<struct ev_loop *> argument.
1790
1791To make it easier to write programs that cope with either variant, the
1792following macros are defined:
1793
1794=over 4
1795
1796=item C<EV_A>, C<EV_A_>
1797
1798This provides the loop I<argument> for functions, if one is required ("ev
1799loop argument"). The C<EV_A> form is used when this is the sole argument,
1800C<EV_A_> is used when other arguments are following. Example:
1801
1802 ev_unref (EV_A);
1803 ev_timer_add (EV_A_ watcher);
1804 ev_loop (EV_A_ 0);
1805
1806It assumes the variable C<loop> of type C<struct ev_loop *> is in scope,
1807which is often provided by the following macro.
1808
1809=item C<EV_P>, C<EV_P_>
1810
1811This provides the loop I<parameter> for functions, if one is required ("ev
1812loop parameter"). The C<EV_P> form is used when this is the sole parameter,
1813C<EV_P_> is used when other parameters are following. Example:
1814
1815 // this is how ev_unref is being declared
1816 static void ev_unref (EV_P);
1817
1818 // this is how you can declare your typical callback
1819 static void cb (EV_P_ ev_timer *w, int revents)
1820
1821It declares a parameter C<loop> of type C<struct ev_loop *>, quite
1822suitable for use with C<EV_A>.
1823
1824=item C<EV_DEFAULT>, C<EV_DEFAULT_>
1825
1826Similar to the other two macros, this gives you the value of the default
1827loop, if multiple loops are supported ("ev loop default").
1828
1829=back
1830
1831Example: Declare and initialise a check watcher, working regardless of
1832wether multiple loops are supported or not.
1833
1834 static void
1835 check_cb (EV_P_ ev_timer *w, int revents)
1836 {
1837 ev_check_stop (EV_A_ w);
1838 }
1839
1840 ev_check check;
1841 ev_check_init (&check, check_cb);
1842 ev_check_start (EV_DEFAULT_ &check);
1843 ev_loop (EV_DEFAULT_ 0);
1844
1845
1846=head1 EMBEDDING
1847
1848Libev can (and often is) directly embedded into host
1849applications. Examples of applications that embed it include the Deliantra
1850Game Server, the EV perl module, the GNU Virtual Private Ethernet (gvpe)
1851and rxvt-unicode.
1852
1853The goal is to enable you to just copy the neecssary files into your
1854source directory without having to change even a single line in them, so
1855you can easily upgrade by simply copying (or having a checked-out copy of
1856libev somewhere in your source tree).
1857
1858=head2 FILESETS
1859
1860Depending on what features you need you need to include one or more sets of files
1861in your app.
1862
1863=head3 CORE EVENT LOOP
1864
1865To include only the libev core (all the C<ev_*> functions), with manual
1866configuration (no autoconf):
1867
1868 #define EV_STANDALONE 1
1869 #include "ev.c"
1870
1871This will automatically include F<ev.h>, too, and should be done in a
1872single C source file only to provide the function implementations. To use
1873it, do the same for F<ev.h> in all files wishing to use this API (best
1874done by writing a wrapper around F<ev.h> that you can include instead and
1875where you can put other configuration options):
1876
1877 #define EV_STANDALONE 1
1878 #include "ev.h"
1879
1880Both header files and implementation files can be compiled with a C++
1881compiler (at least, thats a stated goal, and breakage will be treated
1882as a bug).
1883
1884You need the following files in your source tree, or in a directory
1885in your include path (e.g. in libev/ when using -Ilibev):
1886
1887 ev.h
1888 ev.c
1889 ev_vars.h
1890 ev_wrap.h
1891
1892 ev_win32.c required on win32 platforms only
1893
1894 ev_select.c only when select backend is enabled (which is by default)
1895 ev_poll.c only when poll backend is enabled (disabled by default)
1896 ev_epoll.c only when the epoll backend is enabled (disabled by default)
1897 ev_kqueue.c only when the kqueue backend is enabled (disabled by default)
1898 ev_port.c only when the solaris port backend is enabled (disabled by default)
1899
1900F<ev.c> includes the backend files directly when enabled, so you only need
1901to compile this single file.
1902
1903=head3 LIBEVENT COMPATIBILITY API
1904
1905To include the libevent compatibility API, also include:
1906
1907 #include "event.c"
1908
1909in the file including F<ev.c>, and:
1910
1911 #include "event.h"
1912
1913in the files that want to use the libevent API. This also includes F<ev.h>.
1914
1915You need the following additional files for this:
1916
1917 event.h
1918 event.c
1919
1920=head3 AUTOCONF SUPPORT
1921
1922Instead of using C<EV_STANDALONE=1> and providing your config in
1923whatever way you want, you can also C<m4_include([libev.m4])> in your
1924F<configure.ac> and leave C<EV_STANDALONE> undefined. F<ev.c> will then
1925include F<config.h> and configure itself accordingly.
1926
1927For this of course you need the m4 file:
1928
1929 libev.m4
1930
1931=head2 PREPROCESSOR SYMBOLS/MACROS
1932
1933Libev can be configured via a variety of preprocessor symbols you have to define
1934before including any of its files. The default is not to build for multiplicity
1935and only include the select backend.
1936
1937=over 4
1938
1939=item EV_STANDALONE
1940
1941Must always be C<1> if you do not use autoconf configuration, which
1942keeps libev from including F<config.h>, and it also defines dummy
1943implementations for some libevent functions (such as logging, which is not
1944supported). It will also not define any of the structs usually found in
1945F<event.h> that are not directly supported by the libev core alone.
1946
1947=item EV_USE_MONOTONIC
1948
1949If defined to be C<1>, libev will try to detect the availability of the
1950monotonic clock option at both compiletime and runtime. Otherwise no use
1951of the monotonic clock option will be attempted. If you enable this, you
1952usually have to link against librt or something similar. Enabling it when
1953the functionality isn't available is safe, though, althoguh you have
1954to make sure you link against any libraries where the C<clock_gettime>
1955function is hiding in (often F<-lrt>).
1956
1957=item EV_USE_REALTIME
1958
1959If defined to be C<1>, libev will try to detect the availability of the
1960realtime clock option at compiletime (and assume its availability at
1961runtime if successful). Otherwise no use of the realtime clock option will
1962be attempted. This effectively replaces C<gettimeofday> by C<clock_get
1963(CLOCK_REALTIME, ...)> and will not normally affect correctness. See tzhe note about libraries
1964in the description of C<EV_USE_MONOTONIC>, though.
1965
1966=item EV_USE_SELECT
1967
1968If undefined or defined to be C<1>, libev will compile in support for the
1969C<select>(2) backend. No attempt at autodetection will be done: if no
1970other method takes over, select will be it. Otherwise the select backend
1971will not be compiled in.
1972
1973=item EV_SELECT_USE_FD_SET
1974
1975If defined to C<1>, then the select backend will use the system C<fd_set>
1976structure. This is useful if libev doesn't compile due to a missing
1977C<NFDBITS> or C<fd_mask> definition or it misguesses the bitset layout on
1978exotic systems. This usually limits the range of file descriptors to some
1979low limit such as 1024 or might have other limitations (winsocket only
1980allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation, might
1981influence the size of the C<fd_set> used.
1982
1983=item EV_SELECT_IS_WINSOCKET
1984
1985When defined to C<1>, the select backend will assume that
1986select/socket/connect etc. don't understand file descriptors but
1987wants osf handles on win32 (this is the case when the select to
1988be used is the winsock select). This means that it will call
1989C<_get_osfhandle> on the fd to convert it to an OS handle. Otherwise,
1990it is assumed that all these functions actually work on fds, even
1991on win32. Should not be defined on non-win32 platforms.
1992
1993=item EV_USE_POLL
1994
1995If defined to be C<1>, libev will compile in support for the C<poll>(2)
1996backend. Otherwise it will be enabled on non-win32 platforms. It
1997takes precedence over select.
1998
1999=item EV_USE_EPOLL
2000
2001If defined to be C<1>, libev will compile in support for the Linux
2002C<epoll>(7) backend. Its availability will be detected at runtime,
2003otherwise another method will be used as fallback. This is the
2004preferred backend for GNU/Linux systems.
2005
2006=item EV_USE_KQUEUE
2007
2008If defined to be C<1>, libev will compile in support for the BSD style
2009C<kqueue>(2) backend. Its actual availability will be detected at runtime,
2010otherwise another method will be used as fallback. This is the preferred
2011backend for BSD and BSD-like systems, although on most BSDs kqueue only
2012supports some types of fds correctly (the only platform we found that
2013supports ptys for example was NetBSD), so kqueue might be compiled in, but
2014not be used unless explicitly requested. The best way to use it is to find
2015out whether kqueue supports your type of fd properly and use an embedded
2016kqueue loop.
2017
2018=item EV_USE_PORT
2019
2020If defined to be C<1>, libev will compile in support for the Solaris
202110 port style backend. Its availability will be detected at runtime,
2022otherwise another method will be used as fallback. This is the preferred
2023backend for Solaris 10 systems.
2024
2025=item EV_USE_DEVPOLL
2026
2027reserved for future expansion, works like the USE symbols above.
2028
2029=item EV_USE_INOTIFY
2030
2031If defined to be C<1>, libev will compile in support for the Linux inotify
2032interface to speed up C<ev_stat> watchers. Its actual availability will
2033be detected at runtime.
2034
2035=item EV_H
2036
2037The name of the F<ev.h> header file used to include it. The default if
2038undefined is C<< <ev.h> >> in F<event.h> and C<"ev.h"> in F<ev.c>. This
2039can be used to virtually rename the F<ev.h> header file in case of conflicts.
2040
2041=item EV_CONFIG_H
2042
2043If C<EV_STANDALONE> isn't C<1>, this variable can be used to override
2044F<ev.c>'s idea of where to find the F<config.h> file, similarly to
2045C<EV_H>, above.
2046
2047=item EV_EVENT_H
2048
2049Similarly to C<EV_H>, this macro can be used to override F<event.c>'s idea
2050of how the F<event.h> header can be found.
2051
2052=item EV_PROTOTYPES
2053
2054If defined to be C<0>, then F<ev.h> will not define any function
2055prototypes, but still define all the structs and other symbols. This is
2056occasionally useful if you want to provide your own wrapper functions
2057around libev functions.
2058
2059=item EV_MULTIPLICITY
2060
2061If undefined or defined to C<1>, then all event-loop-specific functions
2062will have the C<struct ev_loop *> as first argument, and you can create
2063additional independent event loops. Otherwise there will be no support
2064for multiple event loops and there is no first event loop pointer
2065argument. Instead, all functions act on the single default loop.
2066
2067=item EV_PERIODIC_ENABLE
2068
2069If undefined or defined to be C<1>, then periodic timers are supported. If
2070defined to be C<0>, then they are not. Disabling them saves a few kB of
2071code.
2072
2073=item EV_EMBED_ENABLE
2074
2075If undefined or defined to be C<1>, then embed watchers are supported. If
2076defined to be C<0>, then they are not.
2077
2078=item EV_STAT_ENABLE
2079
2080If undefined or defined to be C<1>, then stat watchers are supported. If
2081defined to be C<0>, then they are not.
2082
2083=item EV_FORK_ENABLE
2084
2085If undefined or defined to be C<1>, then fork watchers are supported. If
2086defined to be C<0>, then they are not.
2087
2088=item EV_MINIMAL
2089
2090If you need to shave off some kilobytes of code at the expense of some
2091speed, define this symbol to C<1>. Currently only used for gcc to override
2092some inlining decisions, saves roughly 30% codesize of amd64.
2093
2094=item EV_PID_HASHSIZE
2095
2096C<ev_child> watchers use a small hash table to distribute workload by
2097pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more
2098than enough. If you need to manage thousands of children you might want to
2099increase this value (I<must> be a power of two).
2100
2101=item EV_INOTIFY_HASHSIZE
2102
2103C<ev_staz> watchers use a small hash table to distribute workload by
2104inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>),
2105usually more than enough. If you need to manage thousands of C<ev_stat>
2106watchers you might want to increase this value (I<must> be a power of
2107two).
2108
2109=item EV_COMMON
2110
2111By default, all watchers have a C<void *data> member. By redefining
2112this macro to a something else you can include more and other types of
2113members. You have to define it each time you include one of the files,
2114though, and it must be identical each time.
2115
2116For example, the perl EV module uses something like this:
2117
2118 #define EV_COMMON \
2119 SV *self; /* contains this struct */ \
2120 SV *cb_sv, *fh /* note no trailing ";" */
2121
2122=item EV_CB_DECLARE (type)
2123
2124=item EV_CB_INVOKE (watcher, revents)
2125
2126=item ev_set_cb (ev, cb)
2127
2128Can be used to change the callback member declaration in each watcher,
2129and the way callbacks are invoked and set. Must expand to a struct member
2130definition and a statement, respectively. See the F<ev.v> header file for
2131their default definitions. One possible use for overriding these is to
2132avoid the C<struct ev_loop *> as first argument in all cases, or to use
2133method calls instead of plain function calls in C++.
2134
2135=head2 EXAMPLES
2136
2137For a real-world example of a program the includes libev
2138verbatim, you can have a look at the EV perl module
2139(L<http://software.schmorp.de/pkg/EV.html>). It has the libev files in
2140the F<libev/> subdirectory and includes them in the F<EV/EVAPI.h> (public
2141interface) and F<EV.xs> (implementation) files. Only the F<EV.xs> file
2142will be compiled. It is pretty complex because it provides its own header
2143file.
2144
2145The usage in rxvt-unicode is simpler. It has a F<ev_cpp.h> header file
2146that everybody includes and which overrides some autoconf choices:
2147
2148 #define EV_USE_POLL 0
2149 #define EV_MULTIPLICITY 0
2150 #define EV_PERIODICS 0
2151 #define EV_CONFIG_H <config.h>
2152
2153 #include "ev++.h"
2154
2155And a F<ev_cpp.C> implementation file that contains libev proper and is compiled:
2156
2157 #include "ev_cpp.h"
2158 #include "ev.c"
2159
2160
2161=head1 COMPLEXITIES
2162
2163In this section the complexities of (many of) the algorithms used inside
2164libev will be explained. For complexity discussions about backends see the
2165documentation for C<ev_default_init>.
2166
2167=over 4
2168
2169=item Starting and stopping timer/periodic watchers: O(log skipped_other_timers)
2170
2171=item Changing timer/periodic watchers (by autorepeat, again): O(log skipped_other_timers)
2172
2173=item Starting io/check/prepare/idle/signal/child watchers: O(1)
2174
2175=item Stopping check/prepare/idle watchers: O(1)
2176
2177=item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE))
2178
2179=item Finding the next timer per loop iteration: O(1)
2180
2181=item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)
2182
2183=item Activating one watcher: O(1)
2184
2185=back
2186
878 2187
879=head1 AUTHOR 2188=head1 AUTHOR
880 2189
881Marc Lehmann <libev@schmorp.de>. 2190Marc Lehmann <libev@schmorp.de>.
882 2191

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines