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.68 by root, Fri Dec 7 18:09:43 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
271=item C<EVFLAG_FORKCHECK>
272
273Instead of calling C<ev_default_fork> or C<ev_loop_fork> manually after
274a fork, you can also make libev check for a fork in each iteration by
275enabling this flag.
276
277This works by calling C<getpid ()> on every iteration of the loop,
278and thus this might slow down your event loop if you do a lot of loop
279iterations and little real work, but is usually not noticeable (on my
280Linux system for example, C<getpid> is actually a simple 5-insn sequence
281without a syscall and thus I<very> fast, but my Linux system also has
282C<pthread_atfork> which is even faster).
283
284The big advantage of this flag is that you can forget about fork (and
285forget about forgetting to tell libev about forking) when you use this
286flag.
287
288This flag setting cannot be overriden or specified in the C<LIBEV_FLAGS>
289environment variable.
290
150=item C<EVMETHOD_SELECT> (value 1, portable select backend) 291=item C<EVBACKEND_SELECT> (value 1, portable select backend)
151 292
152This is your standard select(2) backend. Not I<completely> standard, as 293This 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, 294libev 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 295but 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 296using this backend. It doesn't scale too well (O(highest_fd)), but its usually
156the fastest backend for a low number of fds. 297the fastest backend for a low number of fds.
157 298
158=item C<EVMETHOD_POLL> (value 2, poll backend, available everywhere except on windows) 299=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
159 300
160And this is your standard poll(2) backend. It's more complicated than 301And 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 302select, 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 303number 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). 304lot of inactive fds). It scales similarly to select, i.e. O(total_fds).
164 305
165=item C<EVMETHOD_EPOLL> (value 4, Linux) 306=item C<EVBACKEND_EPOLL> (value 4, Linux)
166 307
167For few fds, this backend is a bit little slower than poll and select, 308For 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 309but 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 310O(total_fds) where n is the total number of fds (or the highest fd), epoll scales
170either O(1) or O(active_fds). 311either O(1) or O(active_fds).
173result in some caching, there is still a syscall per such incident 314result 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 315(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 316best to avoid that. Also, dup()ed file descriptors might not work very
176well if you register events for both fds. 317well if you register events for both fds.
177 318
319Please note that epoll sometimes generates spurious notifications, so you
320need to use non-blocking I/O or other means to avoid blocking when no data
321(or space) is available.
322
178=item C<EVMETHOD_KQUEUE> (value 8, most BSD clones) 323=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
179 324
180Kqueue deserves special mention, as at the time of this writing, it 325Kqueue deserves special mention, as at the time of this writing, it
181was broken on all BSDs except NetBSD (usually it doesn't work with 326was broken on all BSDs except NetBSD (usually it doesn't work with
182anything but sockets and pipes, except on Darwin, where of course its 327anything but sockets and pipes, except on Darwin, where of course its
183completely useless). For this reason its not being "autodetected" unless 328completely useless). For this reason its not being "autodetected"
184you explicitly specify the flags (i.e. you don't use EVFLAG_AUTO). 329unless you explicitly specify it explicitly in the flags (i.e. using
330C<EVBACKEND_KQUEUE>).
185 331
186It scales in the same way as the epoll backend, but the interface to the 332It 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 333kernel is more efficient (which says nothing about its actual speed, of
188course). While starting and stopping an I/O watcher does not cause an 334course). 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 335extra syscall as with epoll, it still adds up to four event changes per
190incident, so its best to avoid that. 336incident, so its best to avoid that.
191 337
192=item C<EVMETHOD_DEVPOLL> (value 16, Solaris 8) 338=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
193 339
194This is not implemented yet (and might never be). 340This is not implemented yet (and might never be).
195 341
196=item C<EVMETHOD_PORT> (value 32, Solaris 10) 342=item C<EVBACKEND_PORT> (value 32, Solaris 10)
197 343
198This uses the Solaris 10 port mechanism. As with everything on Solaris, 344This uses the Solaris 10 port mechanism. As with everything on Solaris,
199it's really slow, but it still scales very well (O(active_fds)). 345it's really slow, but it still scales very well (O(active_fds)).
200 346
347Please note that solaris ports can result in a lot of spurious
348notifications, so you need to use non-blocking I/O or other means to avoid
349blocking when no data (or space) is available.
350
201=item C<EVMETHOD_ALL> 351=item C<EVBACKEND_ALL>
202 352
203Try all backends (even potentially broken ones that wouldn't be tried 353Try 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 354with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as
205C<EVMETHOD_ALL & ~EVMETHOD_KQUEUE>. 355C<EVBACKEND_ALL & ~EVBACKEND_KQUEUE>.
206 356
207=back 357=back
208 358
209If one or more of these are ored into the flags value, then only these 359If 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 360backends will be tried (in the reverse order as given here). If none are
211specified, most compiled-in backend will be tried, usually in reverse 361specified, most compiled-in backend will be tried, usually in reverse
212order of their flag values :) 362order of their flag values :)
213 363
364The most typical usage is like this:
365
366 if (!ev_default_loop (0))
367 fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
368
369Restrict libev to the select and poll backends, and do not allow
370environment settings to be taken into account:
371
372 ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
373
374Use whatever libev has to offer, but make sure that kqueue is used if
375available (warning, breaks stuff, best use only with your own private
376event loop and only if you know the OS supports your types of fds):
377
378 ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
379
214=item struct ev_loop *ev_loop_new (unsigned int flags) 380=item struct ev_loop *ev_loop_new (unsigned int flags)
215 381
216Similar to C<ev_default_loop>, but always creates a new event loop that is 382Similar 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 383always 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 384handle signal and child watchers, and attempts to do so will be greeted by
219undefined behaviour (or a failed assertion if assertions are enabled). 385undefined behaviour (or a failed assertion if assertions are enabled).
220 386
387Example: Try to create a event loop that uses epoll and nothing else.
388
389 struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV);
390 if (!epoller)
391 fatal ("no epoll found here, maybe it hides under your chair");
392
221=item ev_default_destroy () 393=item ev_default_destroy ()
222 394
223Destroys the default loop again (frees all memory and kernel state 395Destroys the default loop again (frees all memory and kernel state
224etc.). This stops all registered event watchers (by not touching them in 396etc.). None of the active event watchers will be stopped in the normal
225any way whatsoever, although you cannot rely on this :). 397sense, so e.g. C<ev_is_active> might still return true. It is your
398responsibility to either stop all watchers cleanly yoursef I<before>
399calling this function, or cope with the fact afterwards (which is usually
400the easiest thing, youc na just ignore the watchers and/or C<free ()> them
401for example).
226 402
227=item ev_loop_destroy (loop) 403=item ev_loop_destroy (loop)
228 404
229Like C<ev_default_destroy>, but destroys an event loop created by an 405Like C<ev_default_destroy>, but destroys an event loop created by an
230earlier call to C<ev_loop_new>. 406earlier call to C<ev_loop_new>.
244it just in case after a fork. To make this easy, the function will fit in 420it just in case after a fork. To make this easy, the function will fit in
245quite nicely into a call to C<pthread_atfork>: 421quite nicely into a call to C<pthread_atfork>:
246 422
247 pthread_atfork (0, 0, ev_default_fork); 423 pthread_atfork (0, 0, ev_default_fork);
248 424
425At the moment, C<EVBACKEND_SELECT> and C<EVBACKEND_POLL> are safe to use
426without calling this function, so if you force one of those backends you
427do not need to care.
428
249=item ev_loop_fork (loop) 429=item ev_loop_fork (loop)
250 430
251Like C<ev_default_fork>, but acts on an event loop created by 431Like 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 432C<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. 433after fork, and how you do this is entirely your own problem.
254 434
435=item unsigned int ev_loop_count (loop)
436
437Returns the count of loop iterations for the loop, which is identical to
438the number of times libev did poll for new events. It starts at C<0> and
439happily wraps around with enough iterations.
440
441This value can sometimes be useful as a generation counter of sorts (it
442"ticks" the number of loop iterations), as it roughly corresponds with
443C<ev_prepare> and C<ev_check> calls.
444
255=item unsigned int ev_method (loop) 445=item unsigned int ev_backend (loop)
256 446
257Returns one of the C<EVMETHOD_*> flags indicating the event backend in 447Returns one of the C<EVBACKEND_*> flags indicating the event backend in
258use. 448use.
259 449
260=item ev_tstamp ev_now (loop) 450=item ev_tstamp ev_now (loop)
261 451
262Returns the current "event loop time", which is the time the event loop 452Returns the current "event loop time", which is the time the event loop
263got events and started processing them. This timestamp does not change 453received events and started processing them. This timestamp does not
264as long as callbacks are being processed, and this is also the base time 454change 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 455time used for relative timers. You can treat it as the timestamp of the
266occuring (or more correctly, the mainloop finding out about it). 456event occuring (or more correctly, libev finding out about it).
267 457
268=item ev_loop (loop, int flags) 458=item ev_loop (loop, int flags)
269 459
270Finally, this is it, the event handler. This function usually is called 460Finally, this is it, the event handler. This function usually is called
271after you initialised all your watchers and you want to start handling 461after you initialised all your watchers and you want to start handling
272events. 462events.
273 463
274If the flags argument is specified as 0, it will not return until either 464If 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. 465either no event watchers are active anymore or C<ev_unloop> was called.
466
467Please note that an explicit C<ev_unloop> is usually better than
468relying on all watchers to be stopped when deciding when a program has
469finished (especially in interactive programs), but having a program that
470automatically loops as long as it has to and no longer by virtue of
471relying on its watchers stopping correctly is a thing of beauty.
276 472
277A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle 473A 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 474those 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. 475case there are no events and will return after one iteration of the loop.
280 476
281A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if 477A 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 478neccessary) and will handle those and any outstanding ones. It will block
283your process until at least one new event arrives, and will return after 479your process until at least one new event arrives, and will return after
284one iteration of the loop. 480one iteration of the loop. This is useful if you are waiting for some
481external event in conjunction with something not expressible using other
482libev watchers. However, a pair of C<ev_prepare>/C<ev_check> watchers is
483usually a better approach for this kind of thing.
285 484
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: 485Here are the gory details of what C<ev_loop> does:
291 486
292 1. If there are no active watchers (reference count is zero), return. 487 * If there are no active watchers (reference count is zero), return.
293 2. Queue and immediately call all prepare watchers. 488 - Queue prepare watchers and then call all outstanding watchers.
294 3. If we have been forked, recreate the kernel state. 489 - If we have been forked, recreate the kernel state.
295 4. Update the kernel state with all outstanding changes. 490 - Update the kernel state with all outstanding changes.
296 5. Update the "event loop time". 491 - Update the "event loop time".
297 6. Calculate for how long to block. 492 - Calculate for how long to block.
298 7. Block the process, waiting for events. 493 - Block the process, waiting for any events.
494 - Queue all outstanding I/O (fd) events.
299 8. Update the "event loop time" and do time jump handling. 495 - Update the "event loop time" and do time jump handling.
300 9. Queue all outstanding timers. 496 - Queue all outstanding timers.
301 10. Queue all outstanding periodics. 497 - Queue all outstanding periodics.
302 11. If no events are pending now, queue all idle watchers. 498 - If no events are pending now, queue all idle watchers.
303 12. Queue all check watchers. 499 - Queue all check watchers.
304 13. Call all queued watchers in reverse order (i.e. check watchers first). 500 - Call all queued watchers in reverse order (i.e. check watchers first).
501 Signals and child watchers are implemented as I/O watchers, and will
502 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 503 - If ev_unloop has been called or EVLOOP_ONESHOT or EVLOOP_NONBLOCK
306 was used, return, otherwise continue with step #1. 504 were used, return, otherwise continue with step *.
505
506Example: Queue some jobs and then loop until no events are outsanding
507anymore.
508
509 ... queue jobs here, make sure they register event watchers as long
510 ... as they still have work to do (even an idle watcher will do..)
511 ev_loop (my_loop, 0);
512 ... jobs done. yeah!
307 513
308=item ev_unloop (loop, how) 514=item ev_unloop (loop, how)
309 515
310Can be used to make a call to C<ev_loop> return early (but only after it 516Can 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 517has 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 531visible 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 532no 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 533way 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>. 534libraries. Just remember to I<unref after start> and I<ref before stop>.
329 535
536Example: Create a signal watcher, but keep it from keeping C<ev_loop>
537running when nothing else is active.
538
539 struct ev_signal exitsig;
540 ev_signal_init (&exitsig, sig_cb, SIGINT);
541 ev_signal_start (loop, &exitsig);
542 evf_unref (loop);
543
544Example: For some weird reason, unregister the above signal handler again.
545
546 ev_ref (loop);
547 ev_signal_stop (loop, &exitsig);
548
330=back 549=back
550
331 551
332=head1 ANATOMY OF A WATCHER 552=head1 ANATOMY OF A WATCHER
333 553
334A watcher is a structure that you create and register to record your 554A 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 555interest 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 588*) >>), and you can stop watching for events at any time by calling the
369corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>. 589corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>.
370 590
371As long as your watcher is active (has been started but not stopped) you 591As 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 592must not touch the values stored in it. Most specifically you must never
373reinitialise it or call its set method. 593reinitialise 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 594
380Each and every callback receives the event loop pointer as first, the 595Each and every callback receives the event loop pointer as first, the
381registered watcher structure as second, and a bitset of received events as 596registered watcher structure as second, and a bitset of received events as
382third argument. 597third argument.
383 598
407The signal specified in the C<ev_signal> watcher has been received by a thread. 622The signal specified in the C<ev_signal> watcher has been received by a thread.
408 623
409=item C<EV_CHILD> 624=item C<EV_CHILD>
410 625
411The pid specified in the C<ev_child> watcher has received a status change. 626The pid specified in the C<ev_child> watcher has received a status change.
627
628=item C<EV_STAT>
629
630The path specified in the C<ev_stat> watcher changed its attributes somehow.
412 631
413=item C<EV_IDLE> 632=item C<EV_IDLE>
414 633
415The C<ev_idle> watcher has determined that you have nothing better to do. 634The C<ev_idle> watcher has determined that you have nothing better to do.
416 635
424received events. Callbacks of both watcher types can start and stop as 643received 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 644many 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 645(for example, a C<ev_prepare> watcher might start an idle watcher to keep
427C<ev_loop> from blocking). 646C<ev_loop> from blocking).
428 647
648=item C<EV_EMBED>
649
650The embedded event loop specified in the C<ev_embed> watcher needs attention.
651
652=item C<EV_FORK>
653
654The event loop has been resumed in the child process after fork (see
655C<ev_fork>).
656
429=item C<EV_ERROR> 657=item C<EV_ERROR>
430 658
431An unspecified error has occured, the watcher has been stopped. This might 659An unspecified error has occured, the watcher has been stopped. This might
432happen because the watcher could not be properly started because libev 660happen 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 661ran 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 667your 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 668with the error from read() or write(). This will not work in multithreaded
441programs, though, so beware. 669programs, though, so beware.
442 670
443=back 671=back
672
673=head2 GENERIC WATCHER FUNCTIONS
674
675In the following description, C<TYPE> stands for the watcher type,
676e.g. C<timer> for C<ev_timer> watchers and C<io> for C<ev_io> watchers.
677
678=over 4
679
680=item C<ev_init> (ev_TYPE *watcher, callback)
681
682This macro initialises the generic portion of a watcher. The contents
683of the watcher object can be arbitrary (so C<malloc> will do). Only
684the generic parts of the watcher are initialised, you I<need> to call
685the type-specific C<ev_TYPE_set> macro afterwards to initialise the
686type-specific parts. For each type there is also a C<ev_TYPE_init> macro
687which rolls both calls into one.
688
689You can reinitialise a watcher at any time as long as it has been stopped
690(or never started) and there are no pending events outstanding.
691
692The callback is always of type C<void (*)(ev_loop *loop, ev_TYPE *watcher,
693int revents)>.
694
695=item C<ev_TYPE_set> (ev_TYPE *, [args])
696
697This macro initialises the type-specific parts of a watcher. You need to
698call C<ev_init> at least once before you call this macro, but you can
699call C<ev_TYPE_set> any number of times. You must not, however, call this
700macro on a watcher that is active (it can be pending, however, which is a
701difference to the C<ev_init> macro).
702
703Although some watcher types do not have type-specific arguments
704(e.g. C<ev_prepare>) you still need to call its C<set> macro.
705
706=item C<ev_TYPE_init> (ev_TYPE *watcher, callback, [args])
707
708This convinience macro rolls both C<ev_init> and C<ev_TYPE_set> macro
709calls into a single call. This is the most convinient method to initialise
710a watcher. The same limitations apply, of course.
711
712=item C<ev_TYPE_start> (loop *, ev_TYPE *watcher)
713
714Starts (activates) the given watcher. Only active watchers will receive
715events. If the watcher is already active nothing will happen.
716
717=item C<ev_TYPE_stop> (loop *, ev_TYPE *watcher)
718
719Stops the given watcher again (if active) and clears the pending
720status. It is possible that stopped watchers are pending (for example,
721non-repeating timers are being stopped when they become pending), but
722C<ev_TYPE_stop> ensures that the watcher is neither active nor pending. If
723you want to free or reuse the memory used by the watcher it is therefore a
724good idea to always call its C<ev_TYPE_stop> function.
725
726=item bool ev_is_active (ev_TYPE *watcher)
727
728Returns a true value iff the watcher is active (i.e. it has been started
729and not yet been stopped). As long as a watcher is active you must not modify
730it.
731
732=item bool ev_is_pending (ev_TYPE *watcher)
733
734Returns a true value iff the watcher is pending, (i.e. it has outstanding
735events but its callback has not yet been invoked). As long as a watcher
736is pending (but not active) you must not call an init function on it (but
737C<ev_TYPE_set> is safe) and you must make sure the watcher is available to
738libev (e.g. you cnanot C<free ()> it).
739
740=item callback ev_cb (ev_TYPE *watcher)
741
742Returns the callback currently set on the watcher.
743
744=item ev_cb_set (ev_TYPE *watcher, callback)
745
746Change the callback. You can change the callback at virtually any time
747(modulo threads).
748
749=item ev_set_priority (ev_TYPE *watcher, priority)
750
751=item int ev_priority (ev_TYPE *watcher)
752
753Set and query the priority of the watcher. The priority is a small
754integer between C<EV_MAXPRI> (default: C<2>) and C<EV_MINPRI>
755(default: C<-2>). Pending watchers with higher priority will be invoked
756before watchers with lower priority, but priority will not keep watchers
757from being executed (except for C<ev_idle> watchers).
758
759This means that priorities are I<only> used for ordering callback
760invocation after new events have been received. This is useful, for
761example, to reduce latency after idling, or more often, to bind two
762watchers on the same event and make sure one is called first.
763
764If you need to suppress invocation when higher priority events are pending
765you need to look at C<ev_idle> watchers, which provide this functionality.
766
767The default priority used by watchers when no priority has been set is
768always C<0>, which is supposed to not be too high and not be too low :).
769
770Setting a priority outside the range of C<EV_MINPRI> to C<EV_MAXPRI> is
771fine, as long as you do not mind that the priority value you query might
772or might not have been adjusted to be within valid range.
773
774=back
775
444 776
445=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER 777=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
446 778
447Each watcher has, by default, a member C<void *data> that you can change 779Each 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 780and read at any time, libev will completely ignore it. This can be used
466 { 798 {
467 struct my_io *w = (struct my_io *)w_; 799 struct my_io *w = (struct my_io *)w_;
468 ... 800 ...
469 } 801 }
470 802
471More interesting and less C-conformant ways of catsing your callback type 803More interesting and less C-conformant ways of casting your callback type
472have been omitted.... 804instead have been omitted.
805
806Another common scenario is having some data structure with multiple
807watchers:
808
809 struct my_biggy
810 {
811 int some_data;
812 ev_timer t1;
813 ev_timer t2;
814 }
815
816In this case getting the pointer to C<my_biggy> is a bit more complicated,
817you need to use C<offsetof>:
818
819 #include <stddef.h>
820
821 static void
822 t1_cb (EV_P_ struct ev_timer *w, int revents)
823 {
824 struct my_biggy big = (struct my_biggy *
825 (((char *)w) - offsetof (struct my_biggy, t1));
826 }
827
828 static void
829 t2_cb (EV_P_ struct ev_timer *w, int revents)
830 {
831 struct my_biggy big = (struct my_biggy *
832 (((char *)w) - offsetof (struct my_biggy, t2));
833 }
473 834
474 835
475=head1 WATCHER TYPES 836=head1 WATCHER TYPES
476 837
477This section describes each watcher in detail, but will not repeat 838This section describes each watcher in detail, but will not repeat
478information given in the last section. 839information given in the last section. Any initialisation/set macros,
840functions and members specific to the watcher type are explained.
479 841
842Members are additionally marked with either I<[read-only]>, meaning that,
843while the watcher is active, you can look at the member and expect some
844sensible content, but you must not modify it (you can modify it while the
845watcher is stopped to your hearts content), or I<[read-write]>, which
846means you can expect it to have some sensible content while the watcher
847is active, but you can also modify it. Modifying it may not do something
848sensible or take immediate effect (or do anything at all), but libev will
849not crash or malfunction in any way.
850
851
480=head2 C<ev_io> - is this file descriptor readable or writable 852=head2 C<ev_io> - is this file descriptor readable or writable?
481 853
482I/O watchers check whether a file descriptor is readable or writable 854I/O watchers check whether a file descriptor is readable or writable
483in each iteration of the event loop (This behaviour is called 855in each iteration of the event loop, or, more precisely, when reading
484level-triggering because you keep receiving events as long as the 856would 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 857some data. This behaviour is called level-triggering because you keep
486act on the event and neither want to receive future events). 858receiving events as long as the condition persists. Remember you can stop
859the watcher if you don't want to act on the event and neither want to
860receive future events.
487 861
488In general you can register as many read and/or write event watchers per 862In 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 863fd 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 864descriptors to non-blocking mode is also usually a good idea (but not
491required if you know what you are doing). 865required if you know what you are doing).
492 866
493You have to be careful with dup'ed file descriptors, though. Some backends 867You 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 868(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 869descriptors correctly if you register interest in two or more fds pointing
496to the same underlying file/socket etc. description (that is, they share 870to the same underlying file/socket/etc. description (that is, they share
497the same underlying "file open"). 871the same underlying "file open").
498 872
499If you must do this, then force the use of a known-to-be-good backend 873If 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 874(at the time of this writing, this includes only C<EVBACKEND_SELECT> and
501EVMETHOD_POLL). 875C<EVBACKEND_POLL>).
876
877Another thing you have to watch out for is that it is quite easy to
878receive "spurious" readyness notifications, that is your callback might
879be called with C<EV_READ> but a subsequent C<read>(2) will actually block
880because there is no data. Not only are some backends known to create a
881lot of those (for example solaris ports), it is very easy to get into
882this situation even with a relatively standard program structure. Thus
883it is best to always use non-blocking I/O: An extra C<read>(2) returning
884C<EAGAIN> is far preferable to a program hanging until some data arrives.
885
886If you cannot run the fd in non-blocking mode (for example you should not
887play around with an Xlib connection), then you have to seperately re-test
888whether a file descriptor is really ready with a known-to-be good interface
889such as poll (fortunately in our Xlib example, Xlib already does this on
890its own, so its quite safe to use).
502 891
503=over 4 892=over 4
504 893
505=item ev_io_init (ev_io *, callback, int fd, int events) 894=item ev_io_init (ev_io *, callback, int fd, int events)
506 895
507=item ev_io_set (ev_io *, int fd, int events) 896=item ev_io_set (ev_io *, int fd, int events)
508 897
509Configures an C<ev_io> watcher. The fd is the file descriptor to rceeive 898Configures 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 | 899rceeive events for and events is either C<EV_READ>, C<EV_WRITE> or
511EV_WRITE> to receive the given events. 900C<EV_READ | EV_WRITE> to receive the given events.
901
902=item int fd [read-only]
903
904The file descriptor being watched.
905
906=item int events [read-only]
907
908The events being watched.
512 909
513=back 910=back
514 911
912Example: Call C<stdin_readable_cb> when STDIN_FILENO has become, well
913readable, but only once. Since it is likely line-buffered, you could
914attempt to read a whole line in the callback.
915
916 static void
917 stdin_readable_cb (struct ev_loop *loop, struct ev_io *w, int revents)
918 {
919 ev_io_stop (loop, w);
920 .. read from stdin here (or from w->fd) and haqndle any I/O errors
921 }
922
923 ...
924 struct ev_loop *loop = ev_default_init (0);
925 struct ev_io stdin_readable;
926 ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ);
927 ev_io_start (loop, &stdin_readable);
928 ev_loop (loop, 0);
929
930
515=head2 C<ev_timer> - relative and optionally recurring timeouts 931=head2 C<ev_timer> - relative and optionally repeating timeouts
516 932
517Timer watchers are simple relative timers that generate an event after a 933Timer watchers are simple relative timers that generate an event after a
518given time, and optionally repeating in regular intervals after that. 934given time, and optionally repeating in regular intervals after that.
519 935
520The timers are based on real time, that is, if you register an event that 936The timers are based on real time, that is, if you register an event that
555=item ev_timer_again (loop) 971=item ev_timer_again (loop)
556 972
557This will act as if the timer timed out and restart it again if it is 973This will act as if the timer timed out and restart it again if it is
558repeating. The exact semantics are: 974repeating. The exact semantics are:
559 975
976If the timer is pending, its pending status is cleared.
977
560If the timer is started but nonrepeating, stop it. 978If the timer is started but nonrepeating, stop it (as if it timed out).
561 979
562If the timer is repeating, either start it if necessary (with the repeat 980If the timer is repeating, either start it if necessary (with the
563value), or reset the running timer to the repeat value. 981C<repeat> value), or reset the running timer to the C<repeat> value.
564 982
565This sounds a bit complicated, but here is a useful and typical 983This 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 984example: Imagine you have a tcp connection and you want a so-called idle
567timeout, that is, you want to be called when there have been, say, 60 985timeout, that is, you want to be called when there have been, say, 60
568seconds of inactivity on the socket. The easiest way to do this is to 986seconds of inactivity on the socket. The easiest way to do this is to
569configure an C<ev_timer> with after=repeat=60 and calling ev_timer_again each 987configure an C<ev_timer> with a C<repeat> value of C<60> and then call
570time you successfully read or write some data. If you go into an idle 988C<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 989you 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. 990socket, you can C<ev_timer_stop> the timer, and C<ev_timer_again> will
991automatically restart it if need be.
992
993That means you can ignore the C<after> value and C<ev_timer_start>
994altogether and only ever use the C<repeat> value and C<ev_timer_again>:
995
996 ev_timer_init (timer, callback, 0., 5.);
997 ev_timer_again (loop, timer);
998 ...
999 timer->again = 17.;
1000 ev_timer_again (loop, timer);
1001 ...
1002 timer->again = 10.;
1003 ev_timer_again (loop, timer);
1004
1005This is more slightly efficient then stopping/starting the timer each time
1006you want to modify its timeout value.
1007
1008=item ev_tstamp repeat [read-write]
1009
1010The current C<repeat> value. Will be used each time the watcher times out
1011or C<ev_timer_again> is called and determines the next timeout (if any),
1012which is also when any modifications are taken into account.
573 1013
574=back 1014=back
575 1015
1016Example: Create a timer that fires after 60 seconds.
1017
1018 static void
1019 one_minute_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
1020 {
1021 .. one minute over, w is actually stopped right here
1022 }
1023
1024 struct ev_timer mytimer;
1025 ev_timer_init (&mytimer, one_minute_cb, 60., 0.);
1026 ev_timer_start (loop, &mytimer);
1027
1028Example: Create a timeout timer that times out after 10 seconds of
1029inactivity.
1030
1031 static void
1032 timeout_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
1033 {
1034 .. ten seconds without any activity
1035 }
1036
1037 struct ev_timer mytimer;
1038 ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */
1039 ev_timer_again (&mytimer); /* start timer */
1040 ev_loop (loop, 0);
1041
1042 // and in some piece of code that gets executed on any "activity":
1043 // reset the timeout to start ticking again at 10 seconds
1044 ev_timer_again (&mytimer);
1045
1046
576=head2 C<ev_periodic> - to cron or not to cron 1047=head2 C<ev_periodic> - to cron or not to cron?
577 1048
578Periodic watchers are also timers of a kind, but they are very versatile 1049Periodic watchers are also timers of a kind, but they are very versatile
579(and unfortunately a bit complex). 1050(and unfortunately a bit complex).
580 1051
581Unlike C<ev_timer>'s, they are not based on real time (or relative time) 1052Unlike 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 1053but 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 1054to 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 () 1055periodic 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 1056+ 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 1057take 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 1058roughly 10 seconds later and of course not if you reset your system time
588again). 1059again).
589 1060
673Simply stops and restarts the periodic watcher again. This is only useful 1144Simply stops and restarts the periodic watcher again. This is only useful
674when you changed some parameters or the reschedule callback would return 1145when 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 1146a different time than the last time it was called (e.g. in a crond like
676program when the crontabs have changed). 1147program when the crontabs have changed).
677 1148
1149=item ev_tstamp interval [read-write]
1150
1151The current interval value. Can be modified any time, but changes only
1152take effect when the periodic timer fires or C<ev_periodic_again> is being
1153called.
1154
1155=item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write]
1156
1157The current reschedule callback, or C<0>, if this functionality is
1158switched off. Can be changed any time, but changes only take effect when
1159the periodic timer fires or C<ev_periodic_again> is being called.
1160
678=back 1161=back
679 1162
1163Example: Call a callback every hour, or, more precisely, whenever the
1164system clock is divisible by 3600. The callback invocation times have
1165potentially a lot of jittering, but good long-term stability.
1166
1167 static void
1168 clock_cb (struct ev_loop *loop, struct ev_io *w, int revents)
1169 {
1170 ... its now a full hour (UTC, or TAI or whatever your clock follows)
1171 }
1172
1173 struct ev_periodic hourly_tick;
1174 ev_periodic_init (&hourly_tick, clock_cb, 0., 3600., 0);
1175 ev_periodic_start (loop, &hourly_tick);
1176
1177Example: The same as above, but use a reschedule callback to do it:
1178
1179 #include <math.h>
1180
1181 static ev_tstamp
1182 my_scheduler_cb (struct ev_periodic *w, ev_tstamp now)
1183 {
1184 return fmod (now, 3600.) + 3600.;
1185 }
1186
1187 ev_periodic_init (&hourly_tick, clock_cb, 0., 0., my_scheduler_cb);
1188
1189Example: Call a callback every hour, starting now:
1190
1191 struct ev_periodic hourly_tick;
1192 ev_periodic_init (&hourly_tick, clock_cb,
1193 fmod (ev_now (loop), 3600.), 3600., 0);
1194 ev_periodic_start (loop, &hourly_tick);
1195
1196
680=head2 C<ev_signal> - signal me when a signal gets signalled 1197=head2 C<ev_signal> - signal me when a signal gets signalled!
681 1198
682Signal watchers will trigger an event when the process receives a specific 1199Signal watchers will trigger an event when the process receives a specific
683signal one or more times. Even though signals are very asynchronous, libev 1200signal 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 1201will try it's best to deliver signals synchronously, i.e. as part of the
685normal event processing, like any other event. 1202normal event processing, like any other event.
698=item ev_signal_set (ev_signal *, int signum) 1215=item ev_signal_set (ev_signal *, int signum)
699 1216
700Configures the watcher to trigger on the given signal number (usually one 1217Configures the watcher to trigger on the given signal number (usually one
701of the C<SIGxxx> constants). 1218of the C<SIGxxx> constants).
702 1219
1220=item int signum [read-only]
1221
1222The signal the watcher watches out for.
1223
703=back 1224=back
704 1225
1226
705=head2 C<ev_child> - wait for pid status changes 1227=head2 C<ev_child> - watch out for process status changes
706 1228
707Child watchers trigger when your process receives a SIGCHLD in response to 1229Child watchers trigger when your process receives a SIGCHLD in response to
708some child status changes (most typically when a child of yours dies). 1230some child status changes (most typically when a child of yours dies).
709 1231
710=over 4 1232=over 4
718at the C<rstatus> member of the C<ev_child> watcher structure to see 1240at 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 1241the 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 1242C<waitpid> documentation). The C<rpid> member contains the pid of the
721process causing the status change. 1243process causing the status change.
722 1244
1245=item int pid [read-only]
1246
1247The process id this watcher watches out for, or C<0>, meaning any process id.
1248
1249=item int rpid [read-write]
1250
1251The process id that detected a status change.
1252
1253=item int rstatus [read-write]
1254
1255The process exit/trace status caused by C<rpid> (see your systems
1256C<waitpid> and C<sys/wait.h> documentation for details).
1257
723=back 1258=back
724 1259
1260Example: Try to exit cleanly on SIGINT and SIGTERM.
1261
1262 static void
1263 sigint_cb (struct ev_loop *loop, struct ev_signal *w, int revents)
1264 {
1265 ev_unloop (loop, EVUNLOOP_ALL);
1266 }
1267
1268 struct ev_signal signal_watcher;
1269 ev_signal_init (&signal_watcher, sigint_cb, SIGINT);
1270 ev_signal_start (loop, &sigint_cb);
1271
1272
1273=head2 C<ev_stat> - did the file attributes just change?
1274
1275This watches a filesystem path for attribute changes. That is, it calls
1276C<stat> regularly (or when the OS says it changed) and sees if it changed
1277compared to the last time, invoking the callback if it did.
1278
1279The path does not need to exist: changing from "path exists" to "path does
1280not exist" is a status change like any other. The condition "path does
1281not exist" is signified by the C<st_nlink> field being zero (which is
1282otherwise always forced to be at least one) and all the other fields of
1283the stat buffer having unspecified contents.
1284
1285The path I<should> be absolute and I<must not> end in a slash. If it is
1286relative and your working directory changes, the behaviour is undefined.
1287
1288Since there is no standard to do this, the portable implementation simply
1289calls C<stat (2)> regularly on the path to see if it changed somehow. You
1290can specify a recommended polling interval for this case. If you specify
1291a polling interval of C<0> (highly recommended!) then a I<suitable,
1292unspecified default> value will be used (which you can expect to be around
1293five seconds, although this might change dynamically). Libev will also
1294impose a minimum interval which is currently around C<0.1>, but thats
1295usually overkill.
1296
1297This watcher type is not meant for massive numbers of stat watchers,
1298as even with OS-supported change notifications, this can be
1299resource-intensive.
1300
1301At the time of this writing, only the Linux inotify interface is
1302implemented (implementing kqueue support is left as an exercise for the
1303reader). Inotify will be used to give hints only and should not change the
1304semantics of C<ev_stat> watchers, which means that libev sometimes needs
1305to fall back to regular polling again even with inotify, but changes are
1306usually detected immediately, and if the file exists there will be no
1307polling.
1308
1309=over 4
1310
1311=item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)
1312
1313=item ev_stat_set (ev_stat *, const char *path, ev_tstamp interval)
1314
1315Configures the watcher to wait for status changes of the given
1316C<path>. The C<interval> is a hint on how quickly a change is expected to
1317be detected and should normally be specified as C<0> to let libev choose
1318a suitable value. The memory pointed to by C<path> must point to the same
1319path for as long as the watcher is active.
1320
1321The callback will be receive C<EV_STAT> when a change was detected,
1322relative to the attributes at the time the watcher was started (or the
1323last change was detected).
1324
1325=item ev_stat_stat (ev_stat *)
1326
1327Updates the stat buffer immediately with new values. If you change the
1328watched path in your callback, you could call this fucntion to avoid
1329detecting this change (while introducing a race condition). Can also be
1330useful simply to find out the new values.
1331
1332=item ev_statdata attr [read-only]
1333
1334The most-recently detected attributes of the file. Although the type is of
1335C<ev_statdata>, this is usually the (or one of the) C<struct stat> types
1336suitable for your system. If the C<st_nlink> member is C<0>, then there
1337was some error while C<stat>ing the file.
1338
1339=item ev_statdata prev [read-only]
1340
1341The previous attributes of the file. The callback gets invoked whenever
1342C<prev> != C<attr>.
1343
1344=item ev_tstamp interval [read-only]
1345
1346The specified interval.
1347
1348=item const char *path [read-only]
1349
1350The filesystem path that is being watched.
1351
1352=back
1353
1354Example: Watch C</etc/passwd> for attribute changes.
1355
1356 static void
1357 passwd_cb (struct ev_loop *loop, ev_stat *w, int revents)
1358 {
1359 /* /etc/passwd changed in some way */
1360 if (w->attr.st_nlink)
1361 {
1362 printf ("passwd current size %ld\n", (long)w->attr.st_size);
1363 printf ("passwd current atime %ld\n", (long)w->attr.st_mtime);
1364 printf ("passwd current mtime %ld\n", (long)w->attr.st_mtime);
1365 }
1366 else
1367 /* you shalt not abuse printf for puts */
1368 puts ("wow, /etc/passwd is not there, expect problems. "
1369 "if this is windows, they already arrived\n");
1370 }
1371
1372 ...
1373 ev_stat passwd;
1374
1375 ev_stat_init (&passwd, passwd_cb, "/etc/passwd");
1376 ev_stat_start (loop, &passwd);
1377
1378
725=head2 C<ev_idle> - when you've got nothing better to do 1379=head2 C<ev_idle> - when you've got nothing better to do...
726 1380
727Idle watchers trigger events when there are no other events are pending 1381Idle watchers trigger events when no other events of the same or higher
728(prepare, check and other idle watchers do not count). That is, as long 1382priority are pending (prepare, check and other idle watchers do not
729as your process is busy handling sockets or timeouts (or even signals, 1383count).
730imagine) it will not be triggered. But when your process is idle all idle 1384
731watchers are being called again and again, once per event loop iteration - 1385That is, as long as your process is busy handling sockets or timeouts
1386(or even signals, imagine) of the same or higher priority it will not be
1387triggered. But when your process is idle (or only lower-priority watchers
1388are pending), the idle watchers are being called once per event loop
732until stopped, that is, or your process receives more events and becomes 1389iteration - until stopped, that is, or your process receives more events
733busy. 1390and becomes busy again with higher priority stuff.
734 1391
735The most noteworthy effect is that as long as any idle watchers are 1392The most noteworthy effect is that as long as any idle watchers are
736active, the process will not block when waiting for new events. 1393active, the process will not block when waiting for new events.
737 1394
738Apart from keeping your process non-blocking (which is a useful 1395Apart from keeping your process non-blocking (which is a useful
748kind. There is a C<ev_idle_set> macro, but using it is utterly pointless, 1405kind. There is a C<ev_idle_set> macro, but using it is utterly pointless,
749believe me. 1406believe me.
750 1407
751=back 1408=back
752 1409
1410Example: Dynamically allocate an C<ev_idle> watcher, start it, and in the
1411callback, free it. Also, use no error checking, as usual.
1412
1413 static void
1414 idle_cb (struct ev_loop *loop, struct ev_idle *w, int revents)
1415 {
1416 free (w);
1417 // now do something you wanted to do when the program has
1418 // no longer asnything immediate to do.
1419 }
1420
1421 struct ev_idle *idle_watcher = malloc (sizeof (struct ev_idle));
1422 ev_idle_init (idle_watcher, idle_cb);
1423 ev_idle_start (loop, idle_cb);
1424
1425
753=head2 C<ev_prepare> and C<ev_check> - customise your event loop 1426=head2 C<ev_prepare> and C<ev_check> - customise your event loop!
754 1427
755Prepare and check watchers are usually (but not always) used in tandem: 1428Prepare and check watchers are usually (but not always) used in tandem:
756prepare watchers get invoked before the process blocks and check watchers 1429prepare watchers get invoked before the process blocks and check watchers
757afterwards. 1430afterwards.
758 1431
1432You I<must not> call C<ev_loop> or similar functions that enter
1433the current event loop from either C<ev_prepare> or C<ev_check>
1434watchers. Other loops than the current one are fine, however. The
1435rationale behind this is that you do not need to check for recursion in
1436those watchers, i.e. the sequence will always be C<ev_prepare>, blocking,
1437C<ev_check> so if you have one watcher of each kind they will always be
1438called in pairs bracketing the blocking call.
1439
759Their main purpose is to integrate other event mechanisms into libev. This 1440Their main purpose is to integrate other event mechanisms into libev and
760could be used, for example, to track variable changes, implement your own 1441their use is somewhat advanced. This could be used, for example, to track
761watchers, integrate net-snmp or a coroutine library and lots more. 1442variable changes, implement your own watchers, integrate net-snmp or a
1443coroutine library and lots more. They are also occasionally useful if
1444you cache some data and want to flush it before blocking (for example,
1445in X programs you might want to do an C<XFlush ()> in an C<ev_prepare>
1446watcher).
762 1447
763This is done by examining in each prepare call which file descriptors need 1448This 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 1449to 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 1450them and starting an C<ev_timer> watcher for any timeouts (many libraries
766provide just this functionality). Then, in the check watcher you check for 1451provide 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> 1473parameters of any kind. There are C<ev_prepare_set> and C<ev_check_set>
789macros, but using them is utterly, utterly and completely pointless. 1474macros, but using them is utterly, utterly and completely pointless.
790 1475
791=back 1476=back
792 1477
1478Example: To include a library such as adns, you would add IO watchers
1479and a timeout watcher in a prepare handler, as required by libadns, and
1480in a check watcher, destroy them and call into libadns. What follows is
1481pseudo-code only of course:
1482
1483 static ev_io iow [nfd];
1484 static ev_timer tw;
1485
1486 static void
1487 io_cb (ev_loop *loop, ev_io *w, int revents)
1488 {
1489 // set the relevant poll flags
1490 // could also call adns_processreadable etc. here
1491 struct pollfd *fd = (struct pollfd *)w->data;
1492 if (revents & EV_READ ) fd->revents |= fd->events & POLLIN;
1493 if (revents & EV_WRITE) fd->revents |= fd->events & POLLOUT;
1494 }
1495
1496 // create io watchers for each fd and a timer before blocking
1497 static void
1498 adns_prepare_cb (ev_loop *loop, ev_prepare *w, int revents)
1499 {
1500 int timeout = 3600000;
1501 struct pollfd fds [nfd];
1502 // actual code will need to loop here and realloc etc.
1503 adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ()));
1504
1505 /* the callback is illegal, but won't be called as we stop during check */
1506 ev_timer_init (&tw, 0, timeout * 1e-3);
1507 ev_timer_start (loop, &tw);
1508
1509 // create on ev_io per pollfd
1510 for (int i = 0; i < nfd; ++i)
1511 {
1512 ev_io_init (iow + i, io_cb, fds [i].fd,
1513 ((fds [i].events & POLLIN ? EV_READ : 0)
1514 | (fds [i].events & POLLOUT ? EV_WRITE : 0)));
1515
1516 fds [i].revents = 0;
1517 iow [i].data = fds + i;
1518 ev_io_start (loop, iow + i);
1519 }
1520 }
1521
1522 // stop all watchers after blocking
1523 static void
1524 adns_check_cb (ev_loop *loop, ev_check *w, int revents)
1525 {
1526 ev_timer_stop (loop, &tw);
1527
1528 for (int i = 0; i < nfd; ++i)
1529 ev_io_stop (loop, iow + i);
1530
1531 adns_afterpoll (adns, fds, nfd, timeval_from (ev_now (loop));
1532 }
1533
1534
1535=head2 C<ev_embed> - when one backend isn't enough...
1536
1537This is a rather advanced watcher type that lets you embed one event loop
1538into another (currently only C<ev_io> events are supported in the embedded
1539loop, other types of watchers might be handled in a delayed or incorrect
1540fashion and must not be used).
1541
1542There are primarily two reasons you would want that: work around bugs and
1543prioritise I/O.
1544
1545As an example for a bug workaround, the kqueue backend might only support
1546sockets on some platform, so it is unusable as generic backend, but you
1547still want to make use of it because you have many sockets and it scales
1548so nicely. In this case, you would create a kqueue-based loop and embed it
1549into your default loop (which might use e.g. poll). Overall operation will
1550be a bit slower because first libev has to poll and then call kevent, but
1551at least you can use both at what they are best.
1552
1553As for prioritising I/O: rarely you have the case where some fds have
1554to be watched and handled very quickly (with low latency), and even
1555priorities and idle watchers might have too much overhead. In this case
1556you would put all the high priority stuff in one loop and all the rest in
1557a second one, and embed the second one in the first.
1558
1559As long as the watcher is active, the callback will be invoked every time
1560there might be events pending in the embedded loop. The callback must then
1561call C<ev_embed_sweep (mainloop, watcher)> to make a single sweep and invoke
1562their callbacks (you could also start an idle watcher to give the embedded
1563loop strictly lower priority for example). You can also set the callback
1564to C<0>, in which case the embed watcher will automatically execute the
1565embedded loop sweep.
1566
1567As long as the watcher is started it will automatically handle events. The
1568callback will be invoked whenever some events have been handled. You can
1569set the callback to C<0> to avoid having to specify one if you are not
1570interested in that.
1571
1572Also, there have not currently been made special provisions for forking:
1573when you fork, you not only have to call C<ev_loop_fork> on both loops,
1574but you will also have to stop and restart any C<ev_embed> watchers
1575yourself.
1576
1577Unfortunately, not all backends are embeddable, only the ones returned by
1578C<ev_embeddable_backends> are, which, unfortunately, does not include any
1579portable one.
1580
1581So when you want to use this feature you will always have to be prepared
1582that you cannot get an embeddable loop. The recommended way to get around
1583this is to have a separate variables for your embeddable loop, try to
1584create it, and if that fails, use the normal loop for everything:
1585
1586 struct ev_loop *loop_hi = ev_default_init (0);
1587 struct ev_loop *loop_lo = 0;
1588 struct ev_embed embed;
1589
1590 // see if there is a chance of getting one that works
1591 // (remember that a flags value of 0 means autodetection)
1592 loop_lo = ev_embeddable_backends () & ev_recommended_backends ()
1593 ? ev_loop_new (ev_embeddable_backends () & ev_recommended_backends ())
1594 : 0;
1595
1596 // if we got one, then embed it, otherwise default to loop_hi
1597 if (loop_lo)
1598 {
1599 ev_embed_init (&embed, 0, loop_lo);
1600 ev_embed_start (loop_hi, &embed);
1601 }
1602 else
1603 loop_lo = loop_hi;
1604
1605=over 4
1606
1607=item ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)
1608
1609=item ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)
1610
1611Configures the watcher to embed the given loop, which must be
1612embeddable. If the callback is C<0>, then C<ev_embed_sweep> will be
1613invoked automatically, otherwise it is the responsibility of the callback
1614to invoke it (it will continue to be called until the sweep has been done,
1615if you do not want thta, you need to temporarily stop the embed watcher).
1616
1617=item ev_embed_sweep (loop, ev_embed *)
1618
1619Make a single, non-blocking sweep over the embedded loop. This works
1620similarly to C<ev_loop (embedded_loop, EVLOOP_NONBLOCK)>, but in the most
1621apropriate way for embedded loops.
1622
1623=item struct ev_loop *loop [read-only]
1624
1625The embedded event loop.
1626
1627=back
1628
1629
1630=head2 C<ev_fork> - the audacity to resume the event loop after a fork
1631
1632Fork watchers are called when a C<fork ()> was detected (usually because
1633whoever is a good citizen cared to tell libev about it by calling
1634C<ev_default_fork> or C<ev_loop_fork>). The invocation is done before the
1635event loop blocks next and before C<ev_check> watchers are being called,
1636and only in the child after the fork. If whoever good citizen calling
1637C<ev_default_fork> cheats and calls it in the wrong process, the fork
1638handlers will be invoked, too, of course.
1639
1640=over 4
1641
1642=item ev_fork_init (ev_signal *, callback)
1643
1644Initialises and configures the fork watcher - it has no parameters of any
1645kind. There is a C<ev_fork_set> macro, but using it is utterly pointless,
1646believe me.
1647
1648=back
1649
1650
793=head1 OTHER FUNCTIONS 1651=head1 OTHER FUNCTIONS
794 1652
795There are some other functions of possible interest. Described. Here. Now. 1653There are some other functions of possible interest. Described. Here. Now.
796 1654
797=over 4 1655=over 4
826 /* stdin might have data for us, joy! */; 1684 /* stdin might have data for us, joy! */;
827 } 1685 }
828 1686
829 ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0); 1687 ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);
830 1688
831=item ev_feed_event (loop, watcher, int events) 1689=item ev_feed_event (ev_loop *, watcher *, int revents)
832 1690
833Feeds the given event set into the event loop, as if the specified event 1691Feeds 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 1692had happened for the specified watcher (which must be a pointer to an
835initialised but not necessarily started event watcher). 1693initialised but not necessarily started event watcher).
836 1694
837=item ev_feed_fd_event (loop, int fd, int revents) 1695=item ev_feed_fd_event (ev_loop *, int fd, int revents)
838 1696
839Feed an event on the given fd, as if a file descriptor backend detected 1697Feed an event on the given fd, as if a file descriptor backend detected
840the given events it. 1698the given events it.
841 1699
842=item ev_feed_signal_event (loop, int signum) 1700=item ev_feed_signal_event (ev_loop *loop, int signum)
843 1701
844Feed an event as if the given signal occured (loop must be the default loop!). 1702Feed an event as if the given signal occured (C<loop> must be the default
1703loop!).
845 1704
846=back 1705=back
1706
847 1707
848=head1 LIBEVENT EMULATION 1708=head1 LIBEVENT EMULATION
849 1709
850Libev offers a compatibility emulation layer for libevent. It cannot 1710Libev offers a compatibility emulation layer for libevent. It cannot
851emulate the internals of libevent, so here are some usage hints: 1711emulate the internals of libevent, so here are some usage hints:
872 1732
873=back 1733=back
874 1734
875=head1 C++ SUPPORT 1735=head1 C++ SUPPORT
876 1736
877TBD. 1737Libev comes with some simplistic wrapper classes for C++ that mainly allow
1738you to use some convinience methods to start/stop watchers and also change
1739the callback model to a model using method callbacks on objects.
1740
1741To use it,
1742
1743 #include <ev++.h>
1744
1745(it is not installed by default). This automatically includes F<ev.h>
1746and puts all of its definitions (many of them macros) into the global
1747namespace. All C++ specific things are put into the C<ev> namespace.
1748
1749It should support all the same embedding options as F<ev.h>, most notably
1750C<EV_MULTIPLICITY>.
1751
1752Here is a list of things available in the C<ev> namespace:
1753
1754=over 4
1755
1756=item C<ev::READ>, C<ev::WRITE> etc.
1757
1758These are just enum values with the same values as the C<EV_READ> etc.
1759macros from F<ev.h>.
1760
1761=item C<ev::tstamp>, C<ev::now>
1762
1763Aliases to the same types/functions as with the C<ev_> prefix.
1764
1765=item C<ev::io>, C<ev::timer>, C<ev::periodic>, C<ev::idle>, C<ev::sig> etc.
1766
1767For each C<ev_TYPE> watcher in F<ev.h> there is a corresponding class of
1768the same name in the C<ev> namespace, with the exception of C<ev_signal>
1769which is called C<ev::sig> to avoid clashes with the C<signal> macro
1770defines by many implementations.
1771
1772All of those classes have these methods:
1773
1774=over 4
1775
1776=item ev::TYPE::TYPE (object *, object::method *)
1777
1778=item ev::TYPE::TYPE (object *, object::method *, struct ev_loop *)
1779
1780=item ev::TYPE::~TYPE
1781
1782The constructor takes a pointer to an object and a method pointer to
1783the event handler callback to call in this class. The constructor calls
1784C<ev_init> for you, which means you have to call the C<set> method
1785before starting it. If you do not specify a loop then the constructor
1786automatically associates the default loop with this watcher.
1787
1788The destructor automatically stops the watcher if it is active.
1789
1790=item w->set (struct ev_loop *)
1791
1792Associates a different C<struct ev_loop> with this watcher. You can only
1793do this when the watcher is inactive (and not pending either).
1794
1795=item w->set ([args])
1796
1797Basically the same as C<ev_TYPE_set>, with the same args. Must be
1798called at least once. Unlike the C counterpart, an active watcher gets
1799automatically stopped and restarted.
1800
1801=item w->start ()
1802
1803Starts the watcher. Note that there is no C<loop> argument as the
1804constructor already takes the loop.
1805
1806=item w->stop ()
1807
1808Stops the watcher if it is active. Again, no C<loop> argument.
1809
1810=item w->again () C<ev::timer>, C<ev::periodic> only
1811
1812For C<ev::timer> and C<ev::periodic>, this invokes the corresponding
1813C<ev_TYPE_again> function.
1814
1815=item w->sweep () C<ev::embed> only
1816
1817Invokes C<ev_embed_sweep>.
1818
1819=item w->update () C<ev::stat> only
1820
1821Invokes C<ev_stat_stat>.
1822
1823=back
1824
1825=back
1826
1827Example: Define a class with an IO and idle watcher, start one of them in
1828the constructor.
1829
1830 class myclass
1831 {
1832 ev_io io; void io_cb (ev::io &w, int revents);
1833 ev_idle idle void idle_cb (ev::idle &w, int revents);
1834
1835 myclass ();
1836 }
1837
1838 myclass::myclass (int fd)
1839 : io (this, &myclass::io_cb),
1840 idle (this, &myclass::idle_cb)
1841 {
1842 io.start (fd, ev::READ);
1843 }
1844
1845
1846=head1 MACRO MAGIC
1847
1848Libev can be compiled with a variety of options, the most fundemantal is
1849C<EV_MULTIPLICITY>. This option determines whether (most) functions and
1850callbacks have an initial C<struct ev_loop *> argument.
1851
1852To make it easier to write programs that cope with either variant, the
1853following macros are defined:
1854
1855=over 4
1856
1857=item C<EV_A>, C<EV_A_>
1858
1859This provides the loop I<argument> for functions, if one is required ("ev
1860loop argument"). The C<EV_A> form is used when this is the sole argument,
1861C<EV_A_> is used when other arguments are following. Example:
1862
1863 ev_unref (EV_A);
1864 ev_timer_add (EV_A_ watcher);
1865 ev_loop (EV_A_ 0);
1866
1867It assumes the variable C<loop> of type C<struct ev_loop *> is in scope,
1868which is often provided by the following macro.
1869
1870=item C<EV_P>, C<EV_P_>
1871
1872This provides the loop I<parameter> for functions, if one is required ("ev
1873loop parameter"). The C<EV_P> form is used when this is the sole parameter,
1874C<EV_P_> is used when other parameters are following. Example:
1875
1876 // this is how ev_unref is being declared
1877 static void ev_unref (EV_P);
1878
1879 // this is how you can declare your typical callback
1880 static void cb (EV_P_ ev_timer *w, int revents)
1881
1882It declares a parameter C<loop> of type C<struct ev_loop *>, quite
1883suitable for use with C<EV_A>.
1884
1885=item C<EV_DEFAULT>, C<EV_DEFAULT_>
1886
1887Similar to the other two macros, this gives you the value of the default
1888loop, if multiple loops are supported ("ev loop default").
1889
1890=back
1891
1892Example: Declare and initialise a check watcher, utilising the above
1893macros so it will work regardless of whether multiple loops are supported
1894or not.
1895
1896 static void
1897 check_cb (EV_P_ ev_timer *w, int revents)
1898 {
1899 ev_check_stop (EV_A_ w);
1900 }
1901
1902 ev_check check;
1903 ev_check_init (&check, check_cb);
1904 ev_check_start (EV_DEFAULT_ &check);
1905 ev_loop (EV_DEFAULT_ 0);
1906
1907=head1 EMBEDDING
1908
1909Libev can (and often is) directly embedded into host
1910applications. Examples of applications that embed it include the Deliantra
1911Game Server, the EV perl module, the GNU Virtual Private Ethernet (gvpe)
1912and rxvt-unicode.
1913
1914The goal is to enable you to just copy the neecssary files into your
1915source directory without having to change even a single line in them, so
1916you can easily upgrade by simply copying (or having a checked-out copy of
1917libev somewhere in your source tree).
1918
1919=head2 FILESETS
1920
1921Depending on what features you need you need to include one or more sets of files
1922in your app.
1923
1924=head3 CORE EVENT LOOP
1925
1926To include only the libev core (all the C<ev_*> functions), with manual
1927configuration (no autoconf):
1928
1929 #define EV_STANDALONE 1
1930 #include "ev.c"
1931
1932This will automatically include F<ev.h>, too, and should be done in a
1933single C source file only to provide the function implementations. To use
1934it, do the same for F<ev.h> in all files wishing to use this API (best
1935done by writing a wrapper around F<ev.h> that you can include instead and
1936where you can put other configuration options):
1937
1938 #define EV_STANDALONE 1
1939 #include "ev.h"
1940
1941Both header files and implementation files can be compiled with a C++
1942compiler (at least, thats a stated goal, and breakage will be treated
1943as a bug).
1944
1945You need the following files in your source tree, or in a directory
1946in your include path (e.g. in libev/ when using -Ilibev):
1947
1948 ev.h
1949 ev.c
1950 ev_vars.h
1951 ev_wrap.h
1952
1953 ev_win32.c required on win32 platforms only
1954
1955 ev_select.c only when select backend is enabled (which is enabled by default)
1956 ev_poll.c only when poll backend is enabled (disabled by default)
1957 ev_epoll.c only when the epoll backend is enabled (disabled by default)
1958 ev_kqueue.c only when the kqueue backend is enabled (disabled by default)
1959 ev_port.c only when the solaris port backend is enabled (disabled by default)
1960
1961F<ev.c> includes the backend files directly when enabled, so you only need
1962to compile this single file.
1963
1964=head3 LIBEVENT COMPATIBILITY API
1965
1966To include the libevent compatibility API, also include:
1967
1968 #include "event.c"
1969
1970in the file including F<ev.c>, and:
1971
1972 #include "event.h"
1973
1974in the files that want to use the libevent API. This also includes F<ev.h>.
1975
1976You need the following additional files for this:
1977
1978 event.h
1979 event.c
1980
1981=head3 AUTOCONF SUPPORT
1982
1983Instead of using C<EV_STANDALONE=1> and providing your config in
1984whatever way you want, you can also C<m4_include([libev.m4])> in your
1985F<configure.ac> and leave C<EV_STANDALONE> undefined. F<ev.c> will then
1986include F<config.h> and configure itself accordingly.
1987
1988For this of course you need the m4 file:
1989
1990 libev.m4
1991
1992=head2 PREPROCESSOR SYMBOLS/MACROS
1993
1994Libev can be configured via a variety of preprocessor symbols you have to define
1995before including any of its files. The default is not to build for multiplicity
1996and only include the select backend.
1997
1998=over 4
1999
2000=item EV_STANDALONE
2001
2002Must always be C<1> if you do not use autoconf configuration, which
2003keeps libev from including F<config.h>, and it also defines dummy
2004implementations for some libevent functions (such as logging, which is not
2005supported). It will also not define any of the structs usually found in
2006F<event.h> that are not directly supported by the libev core alone.
2007
2008=item EV_USE_MONOTONIC
2009
2010If defined to be C<1>, libev will try to detect the availability of the
2011monotonic clock option at both compiletime and runtime. Otherwise no use
2012of the monotonic clock option will be attempted. If you enable this, you
2013usually have to link against librt or something similar. Enabling it when
2014the functionality isn't available is safe, though, althoguh you have
2015to make sure you link against any libraries where the C<clock_gettime>
2016function is hiding in (often F<-lrt>).
2017
2018=item EV_USE_REALTIME
2019
2020If defined to be C<1>, libev will try to detect the availability of the
2021realtime clock option at compiletime (and assume its availability at
2022runtime if successful). Otherwise no use of the realtime clock option will
2023be attempted. This effectively replaces C<gettimeofday> by C<clock_get
2024(CLOCK_REALTIME, ...)> and will not normally affect correctness. See tzhe note about libraries
2025in the description of C<EV_USE_MONOTONIC>, though.
2026
2027=item EV_USE_SELECT
2028
2029If undefined or defined to be C<1>, libev will compile in support for the
2030C<select>(2) backend. No attempt at autodetection will be done: if no
2031other method takes over, select will be it. Otherwise the select backend
2032will not be compiled in.
2033
2034=item EV_SELECT_USE_FD_SET
2035
2036If defined to C<1>, then the select backend will use the system C<fd_set>
2037structure. This is useful if libev doesn't compile due to a missing
2038C<NFDBITS> or C<fd_mask> definition or it misguesses the bitset layout on
2039exotic systems. This usually limits the range of file descriptors to some
2040low limit such as 1024 or might have other limitations (winsocket only
2041allows 64 sockets). The C<FD_SETSIZE> macro, set before compilation, might
2042influence the size of the C<fd_set> used.
2043
2044=item EV_SELECT_IS_WINSOCKET
2045
2046When defined to C<1>, the select backend will assume that
2047select/socket/connect etc. don't understand file descriptors but
2048wants osf handles on win32 (this is the case when the select to
2049be used is the winsock select). This means that it will call
2050C<_get_osfhandle> on the fd to convert it to an OS handle. Otherwise,
2051it is assumed that all these functions actually work on fds, even
2052on win32. Should not be defined on non-win32 platforms.
2053
2054=item EV_USE_POLL
2055
2056If defined to be C<1>, libev will compile in support for the C<poll>(2)
2057backend. Otherwise it will be enabled on non-win32 platforms. It
2058takes precedence over select.
2059
2060=item EV_USE_EPOLL
2061
2062If defined to be C<1>, libev will compile in support for the Linux
2063C<epoll>(7) backend. Its availability will be detected at runtime,
2064otherwise another method will be used as fallback. This is the
2065preferred backend for GNU/Linux systems.
2066
2067=item EV_USE_KQUEUE
2068
2069If defined to be C<1>, libev will compile in support for the BSD style
2070C<kqueue>(2) backend. Its actual availability will be detected at runtime,
2071otherwise another method will be used as fallback. This is the preferred
2072backend for BSD and BSD-like systems, although on most BSDs kqueue only
2073supports some types of fds correctly (the only platform we found that
2074supports ptys for example was NetBSD), so kqueue might be compiled in, but
2075not be used unless explicitly requested. The best way to use it is to find
2076out whether kqueue supports your type of fd properly and use an embedded
2077kqueue loop.
2078
2079=item EV_USE_PORT
2080
2081If defined to be C<1>, libev will compile in support for the Solaris
208210 port style backend. Its availability will be detected at runtime,
2083otherwise another method will be used as fallback. This is the preferred
2084backend for Solaris 10 systems.
2085
2086=item EV_USE_DEVPOLL
2087
2088reserved for future expansion, works like the USE symbols above.
2089
2090=item EV_USE_INOTIFY
2091
2092If defined to be C<1>, libev will compile in support for the Linux inotify
2093interface to speed up C<ev_stat> watchers. Its actual availability will
2094be detected at runtime.
2095
2096=item EV_H
2097
2098The name of the F<ev.h> header file used to include it. The default if
2099undefined is C<< <ev.h> >> in F<event.h> and C<"ev.h"> in F<ev.c>. This
2100can be used to virtually rename the F<ev.h> header file in case of conflicts.
2101
2102=item EV_CONFIG_H
2103
2104If C<EV_STANDALONE> isn't C<1>, this variable can be used to override
2105F<ev.c>'s idea of where to find the F<config.h> file, similarly to
2106C<EV_H>, above.
2107
2108=item EV_EVENT_H
2109
2110Similarly to C<EV_H>, this macro can be used to override F<event.c>'s idea
2111of how the F<event.h> header can be found.
2112
2113=item EV_PROTOTYPES
2114
2115If defined to be C<0>, then F<ev.h> will not define any function
2116prototypes, but still define all the structs and other symbols. This is
2117occasionally useful if you want to provide your own wrapper functions
2118around libev functions.
2119
2120=item EV_MULTIPLICITY
2121
2122If undefined or defined to C<1>, then all event-loop-specific functions
2123will have the C<struct ev_loop *> as first argument, and you can create
2124additional independent event loops. Otherwise there will be no support
2125for multiple event loops and there is no first event loop pointer
2126argument. Instead, all functions act on the single default loop.
2127
2128=item EV_PERIODIC_ENABLE
2129
2130If undefined or defined to be C<1>, then periodic timers are supported. If
2131defined to be C<0>, then they are not. Disabling them saves a few kB of
2132code.
2133
2134=item EV_IDLE_ENABLE
2135
2136If undefined or defined to be C<1>, then idle watchers are supported. If
2137defined to be C<0>, then they are not. Disabling them saves a few kB of
2138code.
2139
2140=item EV_EMBED_ENABLE
2141
2142If undefined or defined to be C<1>, then embed watchers are supported. If
2143defined to be C<0>, then they are not.
2144
2145=item EV_STAT_ENABLE
2146
2147If undefined or defined to be C<1>, then stat watchers are supported. If
2148defined to be C<0>, then they are not.
2149
2150=item EV_FORK_ENABLE
2151
2152If undefined or defined to be C<1>, then fork watchers are supported. If
2153defined to be C<0>, then they are not.
2154
2155=item EV_MINIMAL
2156
2157If you need to shave off some kilobytes of code at the expense of some
2158speed, define this symbol to C<1>. Currently only used for gcc to override
2159some inlining decisions, saves roughly 30% codesize of amd64.
2160
2161=item EV_PID_HASHSIZE
2162
2163C<ev_child> watchers use a small hash table to distribute workload by
2164pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more
2165than enough. If you need to manage thousands of children you might want to
2166increase this value (I<must> be a power of two).
2167
2168=item EV_INOTIFY_HASHSIZE
2169
2170C<ev_staz> watchers use a small hash table to distribute workload by
2171inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>),
2172usually more than enough. If you need to manage thousands of C<ev_stat>
2173watchers you might want to increase this value (I<must> be a power of
2174two).
2175
2176=item EV_COMMON
2177
2178By default, all watchers have a C<void *data> member. By redefining
2179this macro to a something else you can include more and other types of
2180members. You have to define it each time you include one of the files,
2181though, and it must be identical each time.
2182
2183For example, the perl EV module uses something like this:
2184
2185 #define EV_COMMON \
2186 SV *self; /* contains this struct */ \
2187 SV *cb_sv, *fh /* note no trailing ";" */
2188
2189=item EV_CB_DECLARE (type)
2190
2191=item EV_CB_INVOKE (watcher, revents)
2192
2193=item ev_set_cb (ev, cb)
2194
2195Can be used to change the callback member declaration in each watcher,
2196and the way callbacks are invoked and set. Must expand to a struct member
2197definition and a statement, respectively. See the F<ev.v> header file for
2198their default definitions. One possible use for overriding these is to
2199avoid the C<struct ev_loop *> as first argument in all cases, or to use
2200method calls instead of plain function calls in C++.
2201
2202=head2 EXAMPLES
2203
2204For a real-world example of a program the includes libev
2205verbatim, you can have a look at the EV perl module
2206(L<http://software.schmorp.de/pkg/EV.html>). It has the libev files in
2207the F<libev/> subdirectory and includes them in the F<EV/EVAPI.h> (public
2208interface) and F<EV.xs> (implementation) files. Only the F<EV.xs> file
2209will be compiled. It is pretty complex because it provides its own header
2210file.
2211
2212The usage in rxvt-unicode is simpler. It has a F<ev_cpp.h> header file
2213that everybody includes and which overrides some configure choices:
2214
2215 #define EV_MINIMAL 1
2216 #define EV_USE_POLL 0
2217 #define EV_MULTIPLICITY 0
2218 #define EV_PERIODIC_ENABLE 0
2219 #define EV_STAT_ENABLE 0
2220 #define EV_FORK_ENABLE 0
2221 #define EV_CONFIG_H <config.h>
2222 #define EV_MINPRI 0
2223 #define EV_MAXPRI 0
2224
2225 #include "ev++.h"
2226
2227And a F<ev_cpp.C> implementation file that contains libev proper and is compiled:
2228
2229 #include "ev_cpp.h"
2230 #include "ev.c"
2231
2232
2233=head1 COMPLEXITIES
2234
2235In this section the complexities of (many of) the algorithms used inside
2236libev will be explained. For complexity discussions about backends see the
2237documentation for C<ev_default_init>.
2238
2239=over 4
2240
2241=item Starting and stopping timer/periodic watchers: O(log skipped_other_timers)
2242
2243=item Changing timer/periodic watchers (by autorepeat, again): O(log skipped_other_timers)
2244
2245=item Starting io/check/prepare/idle/signal/child watchers: O(1)
2246
2247=item Stopping check/prepare/idle watchers: O(1)
2248
2249=item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE))
2250
2251=item Finding the next timer per loop iteration: O(1)
2252
2253=item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)
2254
2255=item Activating one watcher: O(1)
2256
2257=back
2258
878 2259
879=head1 AUTHOR 2260=head1 AUTHOR
880 2261
881Marc Lehmann <libev@schmorp.de>. 2262Marc Lehmann <libev@schmorp.de>.
882 2263

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines