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

Comparing libev/ev.pod (file contents):
Revision 1.309 by root, Thu Oct 21 09:23:21 2010 UTC vs.
Revision 1.337 by root, Sun Oct 31 20:20:20 2010 UTC

26 puts ("stdin ready"); 26 puts ("stdin ready");
27 // for one-shot events, one must manually stop the watcher 27 // for one-shot events, one must manually stop the watcher
28 // with its corresponding stop function. 28 // with its corresponding stop function.
29 ev_io_stop (EV_A_ w); 29 ev_io_stop (EV_A_ w);
30 30
31 // this causes all nested ev_loop's to stop iterating 31 // this causes all nested ev_run's to stop iterating
32 ev_unloop (EV_A_ EVUNLOOP_ALL); 32 ev_break (EV_A_ EVBREAK_ALL);
33 } 33 }
34 34
35 // another callback, this time for a time-out 35 // another callback, this time for a time-out
36 static void 36 static void
37 timeout_cb (EV_P_ ev_timer *w, int revents) 37 timeout_cb (EV_P_ ev_timer *w, int revents)
38 { 38 {
39 puts ("timeout"); 39 puts ("timeout");
40 // this causes the innermost ev_loop to stop iterating 40 // this causes the innermost ev_run to stop iterating
41 ev_unloop (EV_A_ EVUNLOOP_ONE); 41 ev_break (EV_A_ EVBREAK_ONE);
42 } 42 }
43 43
44 int 44 int
45 main (void) 45 main (void)
46 { 46 {
47 // use the default event loop unless you have special needs 47 // use the default event loop unless you have special needs
48 struct ev_loop *loop = ev_default_loop (0); 48 struct ev_loop *loop = EV_DEFAULT;
49 49
50 // initialise an io watcher, then start it 50 // initialise an io watcher, then start it
51 // this one will watch for stdin to become readable 51 // this one will watch for stdin to become readable
52 ev_io_init (&stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ); 52 ev_io_init (&stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ);
53 ev_io_start (loop, &stdin_watcher); 53 ev_io_start (loop, &stdin_watcher);
56 // simple non-repeating 5.5 second timeout 56 // simple non-repeating 5.5 second timeout
57 ev_timer_init (&timeout_watcher, timeout_cb, 5.5, 0.); 57 ev_timer_init (&timeout_watcher, timeout_cb, 5.5, 0.);
58 ev_timer_start (loop, &timeout_watcher); 58 ev_timer_start (loop, &timeout_watcher);
59 59
60 // now wait for events to arrive 60 // now wait for events to arrive
61 ev_loop (loop, 0); 61 ev_run (loop, 0);
62 62
63 // unloop was called, so exit 63 // unloop was called, so exit
64 return 0; 64 return 0;
65 } 65 }
66 66
77on event-based programming, nor will it introduce event-based programming 77on event-based programming, nor will it introduce event-based programming
78with libev. 78with libev.
79 79
80Familiarity with event based programming techniques in general is assumed 80Familiarity with event based programming techniques in general is assumed
81throughout this document. 81throughout this document.
82
83=head1 WHAT TO READ WHEN IN A HURRY
84
85This manual tries to be very detailed, but unfortunately, this also makes
86it very long. If you just want to know the basics of libev, I suggest
87reading L<ANATOMY OF A WATCHER>, then the L<EXAMPLE PROGRAM> above and
88look up the missing functions in L<GLOBAL FUNCTIONS> and the C<ev_io> and
89C<ev_timer> sections in L<WATCHER TYPES>.
82 90
83=head1 ABOUT LIBEV 91=head1 ABOUT LIBEV
84 92
85Libev is an event loop: you register interest in certain events (such as a 93Libev is an event loop: you register interest in certain events (such as a
86file descriptor being readable or a timeout occurring), and it will manage 94file descriptor being readable or a timeout occurring), and it will manage
124this argument. 132this argument.
125 133
126=head2 TIME REPRESENTATION 134=head2 TIME REPRESENTATION
127 135
128Libev represents time as a single floating point number, representing 136Libev represents time as a single floating point number, representing
129the (fractional) number of seconds since the (POSIX) epoch (in practise 137the (fractional) number of seconds since the (POSIX) epoch (in practice
130somewhere near the beginning of 1970, details are complicated, don't 138somewhere near the beginning of 1970, details are complicated, don't
131ask). This type is called C<ev_tstamp>, which is what you should use 139ask). This type is called C<ev_tstamp>, which is what you should use
132too. It usually aliases to the C<double> type in C. When you need to do 140too. It usually aliases to the C<double> type in C. When you need to do
133any calculations on it, you should treat it as some floating point value. 141any calculations on it, you should treat it as some floating point value.
134 142
165 173
166=item ev_tstamp ev_time () 174=item ev_tstamp ev_time ()
167 175
168Returns the current time as libev would use it. Please note that the 176Returns the current time as libev would use it. Please note that the
169C<ev_now> function is usually faster and also often returns the timestamp 177C<ev_now> function is usually faster and also often returns the timestamp
170you actually want to know. 178you actually want to know. Also interesting is the combination of
179C<ev_update_now> and C<ev_now>.
171 180
172=item ev_sleep (ev_tstamp interval) 181=item ev_sleep (ev_tstamp interval)
173 182
174Sleep for the given interval: The current thread will be blocked until 183Sleep for the given interval: The current thread will be blocked until
175either it is interrupted or the given time interval has passed. Basically 184either it is interrupted or the given time interval has passed. Basically
192as this indicates an incompatible change. Minor versions are usually 201as this indicates an incompatible change. Minor versions are usually
193compatible to older versions, so a larger minor version alone is usually 202compatible to older versions, so a larger minor version alone is usually
194not a problem. 203not a problem.
195 204
196Example: Make sure we haven't accidentally been linked against the wrong 205Example: Make sure we haven't accidentally been linked against the wrong
197version (note, however, that this will not detect ABI mismatches :). 206version (note, however, that this will not detect other ABI mismatches,
207such as LFS or reentrancy).
198 208
199 assert (("libev version mismatch", 209 assert (("libev version mismatch",
200 ev_version_major () == EV_VERSION_MAJOR 210 ev_version_major () == EV_VERSION_MAJOR
201 && ev_version_minor () >= EV_VERSION_MINOR)); 211 && ev_version_minor () >= EV_VERSION_MINOR));
202 212
213 assert (("sorry, no epoll, no sex", 223 assert (("sorry, no epoll, no sex",
214 ev_supported_backends () & EVBACKEND_EPOLL)); 224 ev_supported_backends () & EVBACKEND_EPOLL));
215 225
216=item unsigned int ev_recommended_backends () 226=item unsigned int ev_recommended_backends ()
217 227
218Return the set of all backends compiled into this binary of libev and also 228Return the set of all backends compiled into this binary of libev and
219recommended for this platform. This set is often smaller than the one 229also recommended for this platform, meaning it will work for most file
230descriptor types. This set is often smaller than the one returned by
220returned by C<ev_supported_backends>, as for example kqueue is broken on 231C<ev_supported_backends>, as for example kqueue is broken on most BSDs
221most BSDs and will not be auto-detected unless you explicitly request it 232and will not be auto-detected unless you explicitly request it (assuming
222(assuming you know what you are doing). This is the set of backends that 233you know what you are doing). This is the set of backends that libev will
223libev will probe for if you specify no backends explicitly. 234probe for if you specify no backends explicitly.
224 235
225=item unsigned int ev_embeddable_backends () 236=item unsigned int ev_embeddable_backends ()
226 237
227Returns the set of backends that are embeddable in other event loops. This 238Returns the set of backends that are embeddable in other event loops. This
228is the theoretical, all-platform, value. To find which backends 239value is platform-specific but can include backends not available on the
229might be supported on the current system, you would need to look at 240current system. To find which embeddable backends might be supported on
230C<ev_embeddable_backends () & ev_supported_backends ()>, likewise for 241the current system, you would need to look at C<ev_embeddable_backends ()
231recommended ones. 242& ev_supported_backends ()>, likewise for recommended ones.
232 243
233See the description of C<ev_embed> watchers for more info. 244See the description of C<ev_embed> watchers for more info.
234 245
235=item ev_set_allocator (void *(*cb)(void *ptr, long size)) [NOT REENTRANT] 246=item ev_set_allocator (void *(*cb)(void *ptr, long size)) [NOT REENTRANT]
236 247
290 ... 301 ...
291 ev_set_syserr_cb (fatal_error); 302 ev_set_syserr_cb (fatal_error);
292 303
293=back 304=back
294 305
295=head1 FUNCTIONS CONTROLLING THE EVENT LOOP 306=head1 FUNCTIONS CONTROLLING EVENT LOOPS
296 307
297An event loop is described by a C<struct ev_loop *> (the C<struct> 308An event loop is described by a C<struct ev_loop *> (the C<struct> is
298is I<not> optional in this case, as there is also an C<ev_loop> 309I<not> optional in this case unless libev 3 compatibility is disabled, as
299I<function>). 310libev 3 had an C<ev_loop> function colliding with the struct name).
300 311
301The library knows two types of such loops, the I<default> loop, which 312The library knows two types of such loops, the I<default> loop, which
302supports signals and child events, and dynamically created loops which do 313supports child process events, and dynamically created event loops which
303not. 314do not.
304 315
305=over 4 316=over 4
306 317
307=item struct ev_loop *ev_default_loop (unsigned int flags) 318=item struct ev_loop *ev_default_loop (unsigned int flags)
308 319
309This will initialise the default event loop if it hasn't been initialised 320This returns the "default" event loop object, which is what you should
310yet and return it. If the default loop could not be initialised, returns 321normally use when you just need "the event loop". Event loop objects and
311false. If it already was initialised it simply returns it (and ignores the 322the C<flags> parameter are described in more detail in the entry for
312flags. If that is troubling you, check C<ev_backend ()> afterwards). 323C<ev_loop_new>.
324
325If the default loop is already initialised then this function simply
326returns it (and ignores the flags. If that is troubling you, check
327C<ev_backend ()> afterwards). Otherwise it will create it with the given
328flags, which should almost always be C<0>, unless the caller is also the
329one calling C<ev_run> or otherwise qualifies as "the main program".
313 330
314If you don't know what event loop to use, use the one returned from this 331If you don't know what event loop to use, use the one returned from this
315function. 332function (or via the C<EV_DEFAULT> macro).
316 333
317Note that this function is I<not> thread-safe, so if you want to use it 334Note that this function is I<not> thread-safe, so if you want to use it
318from multiple threads, you have to lock (note also that this is unlikely, 335from multiple threads, you have to employ some kind of mutex (note also
319as loops cannot be shared easily between threads anyway). 336that this case is unlikely, as loops cannot be shared easily between
337threads anyway).
320 338
321The default loop is the only loop that can handle C<ev_signal> and 339The default loop is the only loop that can handle C<ev_child> watchers,
322C<ev_child> watchers, and to do this, it always registers a handler 340and to do this, it always registers a handler for C<SIGCHLD>. If this is
323for C<SIGCHLD>. If this is a problem for your application you can either 341a problem for your application you can either create a dynamic loop with
324create a dynamic loop with C<ev_loop_new> that doesn't do that, or you 342C<ev_loop_new> which doesn't do that, or you can simply overwrite the
325can simply overwrite the C<SIGCHLD> signal handler I<after> calling 343C<SIGCHLD> signal handler I<after> calling C<ev_default_init>.
326C<ev_default_init>. 344
345Example: This is the most typical usage.
346
347 if (!ev_default_loop (0))
348 fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
349
350Example: Restrict libev to the select and poll backends, and do not allow
351environment settings to be taken into account:
352
353 ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
354
355=item struct ev_loop *ev_loop_new (unsigned int flags)
356
357This will create and initialise a new event loop object. If the loop
358could not be initialised, returns false.
359
360Note that this function I<is> thread-safe, and one common way to use
361libev with threads is indeed to create one loop per thread, and using the
362default loop in the "main" or "initial" thread.
327 363
328The flags argument can be used to specify special behaviour or specific 364The flags argument can be used to specify special behaviour or specific
329backends to use, and is usually specified as C<0> (or C<EVFLAG_AUTO>). 365backends to use, and is usually specified as C<0> (or C<EVFLAG_AUTO>).
330 366
331The following flags are supported: 367The following flags are supported:
427epoll scales either O(1) or O(active_fds). 463epoll scales either O(1) or O(active_fds).
428 464
429The epoll mechanism deserves honorable mention as the most misdesigned 465The epoll mechanism deserves honorable mention as the most misdesigned
430of the more advanced event mechanisms: mere annoyances include silently 466of the more advanced event mechanisms: mere annoyances include silently
431dropping file descriptors, requiring a system call per change per file 467dropping file descriptors, requiring a system call per change per file
432descriptor (and unnecessary guessing of parameters), problems with dup and 468descriptor (and unnecessary guessing of parameters), problems with dup,
469returning before the timeout value requiring additional iterations and so
433so on. The biggest issue is fork races, however - if a program forks then 470on. The biggest issue is fork races, however - if a program forks then
434I<both> parent and child process have to recreate the epoll set, which can 471I<both> parent and child process have to recreate the epoll set, which can
435take considerable time (one syscall per file descriptor) and is of course 472take considerable time (one syscall per file descriptor) and is of course
436hard to detect. 473hard to detect.
437 474
438Epoll is also notoriously buggy - embedding epoll fds I<should> work, but 475Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
549If one or more of the backend flags are or'ed into the flags value, 586If one or more of the backend flags are or'ed into the flags value,
550then only these backends will be tried (in the reverse order as listed 587then only these backends will be tried (in the reverse order as listed
551here). If none are specified, all backends in C<ev_recommended_backends 588here). If none are specified, all backends in C<ev_recommended_backends
552()> will be tried. 589()> will be tried.
553 590
554Example: This is the most typical usage.
555
556 if (!ev_default_loop (0))
557 fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
558
559Example: Restrict libev to the select and poll backends, and do not allow
560environment settings to be taken into account:
561
562 ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
563
564Example: Use whatever libev has to offer, but make sure that kqueue is
565used if available (warning, breaks stuff, best use only with your own
566private event loop and only if you know the OS supports your types of
567fds):
568
569 ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
570
571=item struct ev_loop *ev_loop_new (unsigned int flags)
572
573Similar to C<ev_default_loop>, but always creates a new event loop that is
574always distinct from the default loop.
575
576Note that this function I<is> thread-safe, and one common way to use
577libev with threads is indeed to create one loop per thread, and using the
578default loop in the "main" or "initial" thread.
579
580Example: Try to create a event loop that uses epoll and nothing else. 591Example: Try to create a event loop that uses epoll and nothing else.
581 592
582 struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); 593 struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV);
583 if (!epoller) 594 if (!epoller)
584 fatal ("no epoll found here, maybe it hides under your chair"); 595 fatal ("no epoll found here, maybe it hides under your chair");
585 596
597Example: Use whatever libev has to offer, but make sure that kqueue is
598used if available.
599
600 struct ev_loop *loop = ev_loop_new (ev_recommended_backends () | EVBACKEND_KQUEUE);
601
586=item ev_default_destroy () 602=item ev_loop_destroy (loop)
587 603
588Destroys the default loop (frees all memory and kernel state etc.). None 604Destroys an event loop object (frees all memory and kernel state
589of the active event watchers will be stopped in the normal sense, so 605etc.). None of the active event watchers will be stopped in the normal
590e.g. C<ev_is_active> might still return true. It is your responsibility to 606sense, so e.g. C<ev_is_active> might still return true. It is your
591either stop all watchers cleanly yourself I<before> calling this function, 607responsibility to either stop all watchers cleanly yourself I<before>
592or cope with the fact afterwards (which is usually the easiest thing, you 608calling this function, or cope with the fact afterwards (which is usually
593can just ignore the watchers and/or C<free ()> them for example). 609the easiest thing, you can just ignore the watchers and/or C<free ()> them
610for example).
594 611
595Note that certain global state, such as signal state (and installed signal 612Note that certain global state, such as signal state (and installed signal
596handlers), will not be freed by this function, and related watchers (such 613handlers), will not be freed by this function, and related watchers (such
597as signal and child watchers) would need to be stopped manually. 614as signal and child watchers) would need to be stopped manually.
598 615
599In general it is not advisable to call this function except in the 616This function is normally used on loop objects allocated by
600rare occasion where you really need to free e.g. the signal handling 617C<ev_loop_new>, but it can also be used on the default loop returned by
618C<ev_default_loop>, in which case it is not thread-safe.
619
620Note that it is not advisable to call this function on the default loop
621except in the rare occasion where you really need to free it's resources.
601pipe fds. If you need dynamically allocated loops it is better to use 622If you need dynamically allocated loops it is better to use C<ev_loop_new>
602C<ev_loop_new> and C<ev_loop_destroy>. 623and C<ev_loop_destroy>.
603 624
604=item ev_loop_destroy (loop) 625=item ev_loop_fork (loop)
605 626
606Like C<ev_default_destroy>, but destroys an event loop created by an
607earlier call to C<ev_loop_new>.
608
609=item ev_default_fork ()
610
611This function sets a flag that causes subsequent C<ev_loop> iterations 627This function sets a flag that causes subsequent C<ev_run> iterations to
612to reinitialise the kernel state for backends that have one. Despite the 628reinitialise the kernel state for backends that have one. Despite the
613name, you can call it anytime, but it makes most sense after forking, in 629name, you can call it anytime, but it makes most sense after forking, in
614the child process (or both child and parent, but that again makes little 630the child process. You I<must> call it (or use C<EVFLAG_FORKCHECK>) in the
615sense). You I<must> call it in the child before using any of the libev 631child before resuming or calling C<ev_run>.
616functions, and it will only take effect at the next C<ev_loop> iteration.
617 632
618Again, you I<have> to call it on I<any> loop that you want to re-use after 633Again, you I<have> to call it on I<any> loop that you want to re-use after
619a fork, I<even if you do not plan to use the loop in the parent>. This is 634a fork, I<even if you do not plan to use the loop in the parent>. This is
620because some kernel interfaces *cough* I<kqueue> *cough* do funny things 635because some kernel interfaces *cough* I<kqueue> *cough* do funny things
621during fork. 636during fork.
622 637
623On the other hand, you only need to call this function in the child 638On the other hand, you only need to call this function in the child
624process if and only if you want to use the event loop in the child. If you 639process if and only if you want to use the event loop in the child. If
625just fork+exec or create a new loop in the child, you don't have to call 640you just fork+exec or create a new loop in the child, you don't have to
626it at all. 641call it at all (in fact, C<epoll> is so badly broken that it makes a
642difference, but libev will usually detect this case on its own and do a
643costly reset of the backend).
627 644
628The function itself is quite fast and it's usually not a problem to call 645The function itself is quite fast and it's usually not a problem to call
629it just in case after a fork. To make this easy, the function will fit in 646it just in case after a fork.
630quite nicely into a call to C<pthread_atfork>:
631 647
648Example: Automate calling C<ev_loop_fork> on the default loop when
649using pthreads.
650
651 static void
652 post_fork_child (void)
653 {
654 ev_loop_fork (EV_DEFAULT);
655 }
656
657 ...
632 pthread_atfork (0, 0, ev_default_fork); 658 pthread_atfork (0, 0, post_fork_child);
633
634=item ev_loop_fork (loop)
635
636Like C<ev_default_fork>, but acts on an event loop created by
637C<ev_loop_new>. Yes, you have to call this on every allocated event loop
638after fork that you want to re-use in the child, and how you keep track of
639them is entirely your own problem.
640 659
641=item int ev_is_default_loop (loop) 660=item int ev_is_default_loop (loop)
642 661
643Returns true when the given loop is, in fact, the default loop, and false 662Returns true when the given loop is, in fact, the default loop, and false
644otherwise. 663otherwise.
645 664
646=item unsigned int ev_iteration (loop) 665=item unsigned int ev_iteration (loop)
647 666
648Returns the current iteration count for the loop, which is identical to 667Returns the current iteration count for the event loop, which is identical
649the number of times libev did poll for new events. It starts at C<0> and 668to the number of times libev did poll for new events. It starts at C<0>
650happily wraps around with enough iterations. 669and happily wraps around with enough iterations.
651 670
652This value can sometimes be useful as a generation counter of sorts (it 671This value can sometimes be useful as a generation counter of sorts (it
653"ticks" the number of loop iterations), as it roughly corresponds with 672"ticks" the number of loop iterations), as it roughly corresponds with
654C<ev_prepare> and C<ev_check> calls - and is incremented between the 673C<ev_prepare> and C<ev_check> calls - and is incremented between the
655prepare and check phases. 674prepare and check phases.
656 675
657=item unsigned int ev_depth (loop) 676=item unsigned int ev_depth (loop)
658 677
659Returns the number of times C<ev_loop> was entered minus the number of 678Returns the number of times C<ev_run> was entered minus the number of
660times C<ev_loop> was exited, in other words, the recursion depth. 679times C<ev_run> was exited, in other words, the recursion depth.
661 680
662Outside C<ev_loop>, this number is zero. In a callback, this number is 681Outside C<ev_run>, this number is zero. In a callback, this number is
663C<1>, unless C<ev_loop> was invoked recursively (or from another thread), 682C<1>, unless C<ev_run> was invoked recursively (or from another thread),
664in which case it is higher. 683in which case it is higher.
665 684
666Leaving C<ev_loop> abnormally (setjmp/longjmp, cancelling the thread 685Leaving C<ev_run> abnormally (setjmp/longjmp, cancelling the thread
667etc.), doesn't count as "exit" - consider this as a hint to avoid such 686etc.), doesn't count as "exit" - consider this as a hint to avoid such
668ungentleman behaviour unless it's really convenient. 687ungentleman-like behaviour unless it's really convenient.
669 688
670=item unsigned int ev_backend (loop) 689=item unsigned int ev_backend (loop)
671 690
672Returns one of the C<EVBACKEND_*> flags indicating the event backend in 691Returns one of the C<EVBACKEND_*> flags indicating the event backend in
673use. 692use.
682 701
683=item ev_now_update (loop) 702=item ev_now_update (loop)
684 703
685Establishes the current time by querying the kernel, updating the time 704Establishes the current time by querying the kernel, updating the time
686returned by C<ev_now ()> in the progress. This is a costly operation and 705returned by C<ev_now ()> in the progress. This is a costly operation and
687is usually done automatically within C<ev_loop ()>. 706is usually done automatically within C<ev_run ()>.
688 707
689This function is rarely useful, but when some event callback runs for a 708This function is rarely useful, but when some event callback runs for a
690very long time without entering the event loop, updating libev's idea of 709very long time without entering the event loop, updating libev's idea of
691the current time is a good idea. 710the current time is a good idea.
692 711
694 713
695=item ev_suspend (loop) 714=item ev_suspend (loop)
696 715
697=item ev_resume (loop) 716=item ev_resume (loop)
698 717
699These two functions suspend and resume a loop, for use when the loop is 718These two functions suspend and resume an event loop, for use when the
700not used for a while and timeouts should not be processed. 719loop is not used for a while and timeouts should not be processed.
701 720
702A typical use case would be an interactive program such as a game: When 721A typical use case would be an interactive program such as a game: When
703the user presses C<^Z> to suspend the game and resumes it an hour later it 722the user presses C<^Z> to suspend the game and resumes it an hour later it
704would be best to handle timeouts as if no time had actually passed while 723would be best to handle timeouts as if no time had actually passed while
705the program was suspended. This can be achieved by calling C<ev_suspend> 724the program was suspended. This can be achieved by calling C<ev_suspend>
716without a previous call to C<ev_suspend>. 735without a previous call to C<ev_suspend>.
717 736
718Calling C<ev_suspend>/C<ev_resume> has the side effect of updating the 737Calling C<ev_suspend>/C<ev_resume> has the side effect of updating the
719event loop time (see C<ev_now_update>). 738event loop time (see C<ev_now_update>).
720 739
721=item ev_loop (loop, int flags) 740=item ev_run (loop, int flags)
722 741
723Finally, this is it, the event handler. This function usually is called 742Finally, this is it, the event handler. This function usually is called
724after you have initialised all your watchers and you want to start 743after you have initialised all your watchers and you want to start
725handling events. 744handling events. It will ask the operating system for any new events, call
745the watcher callbacks, an then repeat the whole process indefinitely: This
746is why event loops are called I<loops>.
726 747
727If the flags argument is specified as C<0>, it will not return until 748If the flags argument is specified as C<0>, it will keep handling events
728either no event watchers are active anymore or C<ev_unloop> was called. 749until either no event watchers are active anymore or C<ev_break> was
750called.
729 751
730Please note that an explicit C<ev_unloop> is usually better than 752Please note that an explicit C<ev_break> is usually better than
731relying on all watchers to be stopped when deciding when a program has 753relying on all watchers to be stopped when deciding when a program has
732finished (especially in interactive programs), but having a program 754finished (especially in interactive programs), but having a program
733that automatically loops as long as it has to and no longer by virtue 755that automatically loops as long as it has to and no longer by virtue
734of relying on its watchers stopping correctly, that is truly a thing of 756of relying on its watchers stopping correctly, that is truly a thing of
735beauty. 757beauty.
736 758
737A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle 759A flags value of C<EVRUN_NOWAIT> will look for new events, will handle
738those events and any already outstanding ones, but will not block your 760those events and any already outstanding ones, but will not wait and
739process in case there are no events and will return after one iteration of 761block your process in case there are no events and will return after one
740the loop. 762iteration of the loop. This is sometimes useful to poll and handle new
763events while doing lengthy calculations, to keep the program responsive.
741 764
742A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if 765A flags value of C<EVRUN_ONCE> will look for new events (waiting if
743necessary) and will handle those and any already outstanding ones. It 766necessary) and will handle those and any already outstanding ones. It
744will block your process until at least one new event arrives (which could 767will block your process until at least one new event arrives (which could
745be an event internal to libev itself, so there is no guarantee that a 768be an event internal to libev itself, so there is no guarantee that a
746user-registered callback will be called), and will return after one 769user-registered callback will be called), and will return after one
747iteration of the loop. 770iteration of the loop.
748 771
749This is useful if you are waiting for some external event in conjunction 772This is useful if you are waiting for some external event in conjunction
750with something not expressible using other libev watchers (i.e. "roll your 773with something not expressible using other libev watchers (i.e. "roll your
751own C<ev_loop>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is 774own C<ev_run>"). However, a pair of C<ev_prepare>/C<ev_check> watchers is
752usually a better approach for this kind of thing. 775usually a better approach for this kind of thing.
753 776
754Here are the gory details of what C<ev_loop> does: 777Here are the gory details of what C<ev_run> does:
755 778
779 - Increment loop depth.
780 - Reset the ev_break status.
756 - Before the first iteration, call any pending watchers. 781 - Before the first iteration, call any pending watchers.
782 LOOP:
757 * If EVFLAG_FORKCHECK was used, check for a fork. 783 - If EVFLAG_FORKCHECK was used, check for a fork.
758 - If a fork was detected (by any means), queue and call all fork watchers. 784 - If a fork was detected (by any means), queue and call all fork watchers.
759 - Queue and call all prepare watchers. 785 - Queue and call all prepare watchers.
786 - If ev_break was called, goto FINISH.
760 - If we have been forked, detach and recreate the kernel state 787 - If we have been forked, detach and recreate the kernel state
761 as to not disturb the other process. 788 as to not disturb the other process.
762 - Update the kernel state with all outstanding changes. 789 - Update the kernel state with all outstanding changes.
763 - Update the "event loop time" (ev_now ()). 790 - Update the "event loop time" (ev_now ()).
764 - Calculate for how long to sleep or block, if at all 791 - Calculate for how long to sleep or block, if at all
765 (active idle watchers, EVLOOP_NONBLOCK or not having 792 (active idle watchers, EVRUN_NOWAIT or not having
766 any active watchers at all will result in not sleeping). 793 any active watchers at all will result in not sleeping).
767 - Sleep if the I/O and timer collect interval say so. 794 - Sleep if the I/O and timer collect interval say so.
795 - Increment loop iteration counter.
768 - Block the process, waiting for any events. 796 - Block the process, waiting for any events.
769 - Queue all outstanding I/O (fd) events. 797 - Queue all outstanding I/O (fd) events.
770 - Update the "event loop time" (ev_now ()), and do time jump adjustments. 798 - Update the "event loop time" (ev_now ()), and do time jump adjustments.
771 - Queue all expired timers. 799 - Queue all expired timers.
772 - Queue all expired periodics. 800 - Queue all expired periodics.
773 - Unless any events are pending now, queue all idle watchers. 801 - Queue all idle watchers with priority higher than that of pending events.
774 - Queue all check watchers. 802 - Queue all check watchers.
775 - Call all queued watchers in reverse order (i.e. check watchers first). 803 - Call all queued watchers in reverse order (i.e. check watchers first).
776 Signals and child watchers are implemented as I/O watchers, and will 804 Signals and child watchers are implemented as I/O watchers, and will
777 be handled here by queueing them when their watcher gets executed. 805 be handled here by queueing them when their watcher gets executed.
778 - If ev_unloop has been called, or EVLOOP_ONESHOT or EVLOOP_NONBLOCK 806 - If ev_break has been called, or EVRUN_ONCE or EVRUN_NOWAIT
779 were used, or there are no active watchers, return, otherwise 807 were used, or there are no active watchers, goto FINISH, otherwise
780 continue with step *. 808 continue with step LOOP.
809 FINISH:
810 - Reset the ev_break status iff it was EVBREAK_ONE.
811 - Decrement the loop depth.
812 - Return.
781 813
782Example: Queue some jobs and then loop until no events are outstanding 814Example: Queue some jobs and then loop until no events are outstanding
783anymore. 815anymore.
784 816
785 ... queue jobs here, make sure they register event watchers as long 817 ... queue jobs here, make sure they register event watchers as long
786 ... as they still have work to do (even an idle watcher will do..) 818 ... as they still have work to do (even an idle watcher will do..)
787 ev_loop (my_loop, 0); 819 ev_run (my_loop, 0);
788 ... jobs done or somebody called unloop. yeah! 820 ... jobs done or somebody called unloop. yeah!
789 821
790=item ev_unloop (loop, how) 822=item ev_break (loop, how)
791 823
792Can be used to make a call to C<ev_loop> return early (but only after it 824Can be used to make a call to C<ev_run> return early (but only after it
793has processed all outstanding events). The C<how> argument must be either 825has processed all outstanding events). The C<how> argument must be either
794C<EVUNLOOP_ONE>, which will make the innermost C<ev_loop> call return, or 826C<EVBREAK_ONE>, which will make the innermost C<ev_run> call return, or
795C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return. 827C<EVBREAK_ALL>, which will make all nested C<ev_run> calls return.
796 828
797This "unloop state" will be cleared when entering C<ev_loop> again. 829This "break state" will be cleared when entering C<ev_run> again.
798 830
799It is safe to call C<ev_unloop> from outside any C<ev_loop> calls. 831It is safe to call C<ev_break> from outside any C<ev_run> calls, too.
800 832
801=item ev_ref (loop) 833=item ev_ref (loop)
802 834
803=item ev_unref (loop) 835=item ev_unref (loop)
804 836
805Ref/unref can be used to add or remove a reference count on the event 837Ref/unref can be used to add or remove a reference count on the event
806loop: Every watcher keeps one reference, and as long as the reference 838loop: Every watcher keeps one reference, and as long as the reference
807count is nonzero, C<ev_loop> will not return on its own. 839count is nonzero, C<ev_run> will not return on its own.
808 840
809This is useful when you have a watcher that you never intend to 841This is useful when you have a watcher that you never intend to
810unregister, but that nevertheless should not keep C<ev_loop> from 842unregister, but that nevertheless should not keep C<ev_run> from
811returning. In such a case, call C<ev_unref> after starting, and C<ev_ref> 843returning. In such a case, call C<ev_unref> after starting, and C<ev_ref>
812before stopping it. 844before stopping it.
813 845
814As an example, libev itself uses this for its internal signal pipe: It 846As an example, libev itself uses this for its internal signal pipe: It
815is not visible to the libev user and should not keep C<ev_loop> from 847is not visible to the libev user and should not keep C<ev_run> from
816exiting if no event watchers registered by it are active. It is also an 848exiting if no event watchers registered by it are active. It is also an
817excellent way to do this for generic recurring timers or from within 849excellent way to do this for generic recurring timers or from within
818third-party libraries. Just remember to I<unref after start> and I<ref 850third-party libraries. Just remember to I<unref after start> and I<ref
819before stop> (but only if the watcher wasn't active before, or was active 851before stop> (but only if the watcher wasn't active before, or was active
820before, respectively. Note also that libev might stop watchers itself 852before, respectively. Note also that libev might stop watchers itself
821(e.g. non-repeating timers) in which case you have to C<ev_ref> 853(e.g. non-repeating timers) in which case you have to C<ev_ref>
822in the callback). 854in the callback).
823 855
824Example: Create a signal watcher, but keep it from keeping C<ev_loop> 856Example: Create a signal watcher, but keep it from keeping C<ev_run>
825running when nothing else is active. 857running when nothing else is active.
826 858
827 ev_signal exitsig; 859 ev_signal exitsig;
828 ev_signal_init (&exitsig, sig_cb, SIGINT); 860 ev_signal_init (&exitsig, sig_cb, SIGINT);
829 ev_signal_start (loop, &exitsig); 861 ev_signal_start (loop, &exitsig);
892 ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01); 924 ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);
893 925
894=item ev_invoke_pending (loop) 926=item ev_invoke_pending (loop)
895 927
896This call will simply invoke all pending watchers while resetting their 928This call will simply invoke all pending watchers while resetting their
897pending state. Normally, C<ev_loop> does this automatically when required, 929pending state. Normally, C<ev_run> does this automatically when required,
898but when overriding the invoke callback this call comes handy. 930but when overriding the invoke callback this call comes handy. This
931function can be invoked from a watcher - this can be useful for example
932when you want to do some lengthy calculation and want to pass further
933event handling to another thread (you still have to make sure only one
934thread executes within C<ev_invoke_pending> or C<ev_run> of course).
899 935
900=item int ev_pending_count (loop) 936=item int ev_pending_count (loop)
901 937
902Returns the number of pending watchers - zero indicates that no watchers 938Returns the number of pending watchers - zero indicates that no watchers
903are pending. 939are pending.
904 940
905=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P)) 941=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P))
906 942
907This overrides the invoke pending functionality of the loop: Instead of 943This overrides the invoke pending functionality of the loop: Instead of
908invoking all pending watchers when there are any, C<ev_loop> will call 944invoking all pending watchers when there are any, C<ev_run> will call
909this callback instead. This is useful, for example, when you want to 945this callback instead. This is useful, for example, when you want to
910invoke the actual watchers inside another context (another thread etc.). 946invoke the actual watchers inside another context (another thread etc.).
911 947
912If you want to reset the callback, use C<ev_invoke_pending> as new 948If you want to reset the callback, use C<ev_invoke_pending> as new
913callback. 949callback.
916 952
917Sometimes you want to share the same loop between multiple threads. This 953Sometimes you want to share the same loop between multiple threads. This
918can be done relatively simply by putting mutex_lock/unlock calls around 954can be done relatively simply by putting mutex_lock/unlock calls around
919each call to a libev function. 955each call to a libev function.
920 956
921However, C<ev_loop> can run an indefinite time, so it is not feasible to 957However, C<ev_run> can run an indefinite time, so it is not feasible
922wait for it to return. One way around this is to wake up the loop via 958to wait for it to return. One way around this is to wake up the event
923C<ev_unloop> and C<av_async_send>, another way is to set these I<release> 959loop via C<ev_break> and C<av_async_send>, another way is to set these
924and I<acquire> callbacks on the loop. 960I<release> and I<acquire> callbacks on the loop.
925 961
926When set, then C<release> will be called just before the thread is 962When set, then C<release> will be called just before the thread is
927suspended waiting for new events, and C<acquire> is called just 963suspended waiting for new events, and C<acquire> is called just
928afterwards. 964afterwards.
929 965
932 968
933While event loop modifications are allowed between invocations of 969While event loop modifications are allowed between invocations of
934C<release> and C<acquire> (that's their only purpose after all), no 970C<release> and C<acquire> (that's their only purpose after all), no
935modifications done will affect the event loop, i.e. adding watchers will 971modifications done will affect the event loop, i.e. adding watchers will
936have no effect on the set of file descriptors being watched, or the time 972have no effect on the set of file descriptors being watched, or the time
937waited. Use an C<ev_async> watcher to wake up C<ev_loop> when you want it 973waited. Use an C<ev_async> watcher to wake up C<ev_run> when you want it
938to take note of any changes you made. 974to take note of any changes you made.
939 975
940In theory, threads executing C<ev_loop> will be async-cancel safe between 976In theory, threads executing C<ev_run> will be async-cancel safe between
941invocations of C<release> and C<acquire>. 977invocations of C<release> and C<acquire>.
942 978
943See also the locking example in the C<THREADS> section later in this 979See also the locking example in the C<THREADS> section later in this
944document. 980document.
945 981
975 1011
976In the following description, uppercase C<TYPE> in names stands for the 1012In the following description, uppercase C<TYPE> in names stands for the
977watcher type, e.g. C<ev_TYPE_start> can mean C<ev_timer_start> for timer 1013watcher type, e.g. C<ev_TYPE_start> can mean C<ev_timer_start> for timer
978watchers and C<ev_io_start> for I/O watchers. 1014watchers and C<ev_io_start> for I/O watchers.
979 1015
980A watcher is a structure that you create and register to record your 1016A watcher is an opaque structure that you allocate and register to record
981interest in some event. For instance, if you want to wait for STDIN to 1017your interest in some event. To make a concrete example, imagine you want
982become readable, you would create an C<ev_io> watcher for that: 1018to wait for STDIN to become readable, you would create an C<ev_io> watcher
1019for that:
983 1020
984 static void my_cb (struct ev_loop *loop, ev_io *w, int revents) 1021 static void my_cb (struct ev_loop *loop, ev_io *w, int revents)
985 { 1022 {
986 ev_io_stop (w); 1023 ev_io_stop (w);
987 ev_unloop (loop, EVUNLOOP_ALL); 1024 ev_break (loop, EVBREAK_ALL);
988 } 1025 }
989 1026
990 struct ev_loop *loop = ev_default_loop (0); 1027 struct ev_loop *loop = ev_default_loop (0);
991 1028
992 ev_io stdin_watcher; 1029 ev_io stdin_watcher;
993 1030
994 ev_init (&stdin_watcher, my_cb); 1031 ev_init (&stdin_watcher, my_cb);
995 ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ); 1032 ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ);
996 ev_io_start (loop, &stdin_watcher); 1033 ev_io_start (loop, &stdin_watcher);
997 1034
998 ev_loop (loop, 0); 1035 ev_run (loop, 0);
999 1036
1000As you can see, you are responsible for allocating the memory for your 1037As you can see, you are responsible for allocating the memory for your
1001watcher structures (and it is I<usually> a bad idea to do this on the 1038watcher structures (and it is I<usually> a bad idea to do this on the
1002stack). 1039stack).
1003 1040
1004Each watcher has an associated watcher structure (called C<struct ev_TYPE> 1041Each watcher has an associated watcher structure (called C<struct ev_TYPE>
1005or simply C<ev_TYPE>, as typedefs are provided for all watcher structs). 1042or simply C<ev_TYPE>, as typedefs are provided for all watcher structs).
1006 1043
1007Each watcher structure must be initialised by a call to C<ev_init 1044Each watcher structure must be initialised by a call to C<ev_init (watcher
1008(watcher *, callback)>, which expects a callback to be provided. This 1045*, callback)>, which expects a callback to be provided. This callback is
1009callback gets invoked each time the event occurs (or, in the case of I/O 1046invoked each time the event occurs (or, in the case of I/O watchers, each
1010watchers, each time the event loop detects that the file descriptor given 1047time the event loop detects that the file descriptor given is readable
1011is readable and/or writable). 1048and/or writable).
1012 1049
1013Each watcher type further has its own C<< ev_TYPE_set (watcher *, ...) >> 1050Each watcher type further has its own C<< ev_TYPE_set (watcher *, ...) >>
1014macro to configure it, with arguments specific to the watcher type. There 1051macro to configure it, with arguments specific to the watcher type. There
1015is also a macro to combine initialisation and setting in one call: C<< 1052is also a macro to combine initialisation and setting in one call: C<<
1016ev_TYPE_init (watcher *, callback, ...) >>. 1053ev_TYPE_init (watcher *, callback, ...) >>.
1067 1104
1068=item C<EV_PREPARE> 1105=item C<EV_PREPARE>
1069 1106
1070=item C<EV_CHECK> 1107=item C<EV_CHECK>
1071 1108
1072All C<ev_prepare> watchers are invoked just I<before> C<ev_loop> starts 1109All C<ev_prepare> watchers are invoked just I<before> C<ev_run> starts
1073to gather new events, and all C<ev_check> watchers are invoked just after 1110to gather new events, and all C<ev_check> watchers are invoked just after
1074C<ev_loop> has gathered them, but before it invokes any callbacks for any 1111C<ev_run> has gathered them, but before it invokes any callbacks for any
1075received events. Callbacks of both watcher types can start and stop as 1112received events. Callbacks of both watcher types can start and stop as
1076many watchers as they want, and all of them will be taken into account 1113many watchers as they want, and all of them will be taken into account
1077(for example, a C<ev_prepare> watcher might start an idle watcher to keep 1114(for example, a C<ev_prepare> watcher might start an idle watcher to keep
1078C<ev_loop> from blocking). 1115C<ev_run> from blocking).
1079 1116
1080=item C<EV_EMBED> 1117=item C<EV_EMBED>
1081 1118
1082The embedded event loop specified in the C<ev_embed> watcher needs attention. 1119The embedded event loop specified in the C<ev_embed> watcher needs attention.
1083 1120
1084=item C<EV_FORK> 1121=item C<EV_FORK>
1085 1122
1086The event loop has been resumed in the child process after fork (see 1123The event loop has been resumed in the child process after fork (see
1087C<ev_fork>). 1124C<ev_fork>).
1125
1126=item C<EV_CLEANUP>
1127
1128The event loop is about to be destroyed (see C<ev_cleanup>).
1088 1129
1089=item C<EV_ASYNC> 1130=item C<EV_ASYNC>
1090 1131
1091The given async watcher has been asynchronously notified (see C<ev_async>). 1132The given async watcher has been asynchronously notified (see C<ev_async>).
1092 1133
1264 1305
1265See also C<ev_feed_fd_event> and C<ev_feed_signal_event> for related 1306See also C<ev_feed_fd_event> and C<ev_feed_signal_event> for related
1266functions that do not need a watcher. 1307functions that do not need a watcher.
1267 1308
1268=back 1309=back
1269
1270 1310
1271=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER 1311=head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
1272 1312
1273Each watcher has, by default, a member C<void *data> that you can change 1313Each watcher has, by default, a member C<void *data> that you can change
1274and read at any time: libev will completely ignore it. This can be used 1314and read at any time: libev will completely ignore it. This can be used
1330 t2_cb (EV_P_ ev_timer *w, int revents) 1370 t2_cb (EV_P_ ev_timer *w, int revents)
1331 { 1371 {
1332 struct my_biggy big = (struct my_biggy *) 1372 struct my_biggy big = (struct my_biggy *)
1333 (((char *)w) - offsetof (struct my_biggy, t2)); 1373 (((char *)w) - offsetof (struct my_biggy, t2));
1334 } 1374 }
1375
1376=head2 WATCHER STATES
1377
1378There are various watcher states mentioned throughout this manual -
1379active, pending and so on. In this section these states and the rules to
1380transition between them will be described in more detail - and while these
1381rules might look complicated, they usually do "the right thing".
1382
1383=over 4
1384
1385=item initialiased
1386
1387Before a watcher can be registered with the event looop it has to be
1388initialised. This can be done with a call to C<ev_TYPE_init>, or calls to
1389C<ev_init> followed by the watcher-specific C<ev_TYPE_set> function.
1390
1391In this state it is simply some block of memory that is suitable for use
1392in an event loop. It can be moved around, freed, reused etc. at will.
1393
1394=item started/running/active
1395
1396Once a watcher has been started with a call to C<ev_TYPE_start> it becomes
1397property of the event loop, and is actively waiting for events. While in
1398this state it cannot be accessed (except in a few documented ways), moved,
1399freed or anything else - the only legal thing is to keep a pointer to it,
1400and call libev functions on it that are documented to work on active watchers.
1401
1402=item pending
1403
1404If a watcher is active and libev determines that an event it is interested
1405in has occurred (such as a timer expiring), it will become pending. It will
1406stay in this pending state until either it is stopped or its callback is
1407about to be invoked, so it is not normally pending inside the watcher
1408callback.
1409
1410The watcher might or might not be active while it is pending (for example,
1411an expired non-repeating timer can be pending but no longer active). If it
1412is stopped, it can be freely accessed (e.g. by calling C<ev_TYPE_set>),
1413but it is still property of the event loop at this time, so cannot be
1414moved, freed or reused. And if it is active the rules described in the
1415previous item still apply.
1416
1417It is also possible to feed an event on a watcher that is not active (e.g.
1418via C<ev_feed_event>), in which case it becomes pending without being
1419active.
1420
1421=item stopped
1422
1423A watcher can be stopped implicitly by libev (in which case it might still
1424be pending), or explicitly by calling its C<ev_TYPE_stop> function. The
1425latter will clear any pending state the watcher might be in, regardless
1426of whether it was active or not, so stopping a watcher explicitly before
1427freeing it is often a good idea.
1428
1429While stopped (and not pending) the watcher is essentially in the
1430initialised state, that is it can be reused, moved, modified in any way
1431you wish.
1432
1433=back
1335 1434
1336=head2 WATCHER PRIORITY MODELS 1435=head2 WATCHER PRIORITY MODELS
1337 1436
1338Many event loops support I<watcher priorities>, which are usually small 1437Many event loops support I<watcher priorities>, which are usually small
1339integers that influence the ordering of event callback invocation 1438integers that influence the ordering of event callback invocation
1624 ... 1723 ...
1625 struct ev_loop *loop = ev_default_init (0); 1724 struct ev_loop *loop = ev_default_init (0);
1626 ev_io stdin_readable; 1725 ev_io stdin_readable;
1627 ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ); 1726 ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ);
1628 ev_io_start (loop, &stdin_readable); 1727 ev_io_start (loop, &stdin_readable);
1629 ev_loop (loop, 0); 1728 ev_run (loop, 0);
1630 1729
1631 1730
1632=head2 C<ev_timer> - relative and optionally repeating timeouts 1731=head2 C<ev_timer> - relative and optionally repeating timeouts
1633 1732
1634Timer watchers are simple relative timers that generate an event after a 1733Timer watchers are simple relative timers that generate an event after a
1643The callback is guaranteed to be invoked only I<after> its timeout has 1742The callback is guaranteed to be invoked only I<after> its timeout has
1644passed (not I<at>, so on systems with very low-resolution clocks this 1743passed (not I<at>, so on systems with very low-resolution clocks this
1645might introduce a small delay). If multiple timers become ready during the 1744might introduce a small delay). If multiple timers become ready during the
1646same loop iteration then the ones with earlier time-out values are invoked 1745same loop iteration then the ones with earlier time-out values are invoked
1647before ones of the same priority with later time-out values (but this is 1746before ones of the same priority with later time-out values (but this is
1648no longer true when a callback calls C<ev_loop> recursively). 1747no longer true when a callback calls C<ev_run> recursively).
1649 1748
1650=head3 Be smart about timeouts 1749=head3 Be smart about timeouts
1651 1750
1652Many real-world problems involve some kind of timeout, usually for error 1751Many real-world problems involve some kind of timeout, usually for error
1653recovery. A typical example is an HTTP request - if the other side hangs, 1752recovery. A typical example is an HTTP request - if the other side hangs,
1824 1923
1825=head3 The special problem of time updates 1924=head3 The special problem of time updates
1826 1925
1827Establishing the current time is a costly operation (it usually takes at 1926Establishing the current time is a costly operation (it usually takes at
1828least two system calls): EV therefore updates its idea of the current 1927least two system calls): EV therefore updates its idea of the current
1829time only before and after C<ev_loop> collects new events, which causes a 1928time only before and after C<ev_run> collects new events, which causes a
1830growing difference between C<ev_now ()> and C<ev_time ()> when handling 1929growing difference between C<ev_now ()> and C<ev_time ()> when handling
1831lots of events in one iteration. 1930lots of events in one iteration.
1832 1931
1833The relative timeouts are calculated relative to the C<ev_now ()> 1932The relative timeouts are calculated relative to the C<ev_now ()>
1834time. This is usually the right thing as this timestamp refers to the time 1933time. This is usually the right thing as this timestamp refers to the time
1951 } 2050 }
1952 2051
1953 ev_timer mytimer; 2052 ev_timer mytimer;
1954 ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */ 2053 ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */
1955 ev_timer_again (&mytimer); /* start timer */ 2054 ev_timer_again (&mytimer); /* start timer */
1956 ev_loop (loop, 0); 2055 ev_run (loop, 0);
1957 2056
1958 // and in some piece of code that gets executed on any "activity": 2057 // and in some piece of code that gets executed on any "activity":
1959 // reset the timeout to start ticking again at 10 seconds 2058 // reset the timeout to start ticking again at 10 seconds
1960 ev_timer_again (&mytimer); 2059 ev_timer_again (&mytimer);
1961 2060
1987 2086
1988As with timers, the callback is guaranteed to be invoked only when the 2087As with timers, the callback is guaranteed to be invoked only when the
1989point in time where it is supposed to trigger has passed. If multiple 2088point in time where it is supposed to trigger has passed. If multiple
1990timers become ready during the same loop iteration then the ones with 2089timers become ready during the same loop iteration then the ones with
1991earlier time-out values are invoked before ones with later time-out values 2090earlier time-out values are invoked before ones with later time-out values
1992(but this is no longer true when a callback calls C<ev_loop> recursively). 2091(but this is no longer true when a callback calls C<ev_run> recursively).
1993 2092
1994=head3 Watcher-Specific Functions and Data Members 2093=head3 Watcher-Specific Functions and Data Members
1995 2094
1996=over 4 2095=over 4
1997 2096
2235Example: Try to exit cleanly on SIGINT. 2334Example: Try to exit cleanly on SIGINT.
2236 2335
2237 static void 2336 static void
2238 sigint_cb (struct ev_loop *loop, ev_signal *w, int revents) 2337 sigint_cb (struct ev_loop *loop, ev_signal *w, int revents)
2239 { 2338 {
2240 ev_unloop (loop, EVUNLOOP_ALL); 2339 ev_break (loop, EVBREAK_ALL);
2241 } 2340 }
2242 2341
2243 ev_signal signal_watcher; 2342 ev_signal signal_watcher;
2244 ev_signal_init (&signal_watcher, sigint_cb, SIGINT); 2343 ev_signal_init (&signal_watcher, sigint_cb, SIGINT);
2245 ev_signal_start (loop, &signal_watcher); 2344 ev_signal_start (loop, &signal_watcher);
2631 2730
2632Prepare and check watchers are usually (but not always) used in pairs: 2731Prepare and check watchers are usually (but not always) used in pairs:
2633prepare watchers get invoked before the process blocks and check watchers 2732prepare watchers get invoked before the process blocks and check watchers
2634afterwards. 2733afterwards.
2635 2734
2636You I<must not> call C<ev_loop> or similar functions that enter 2735You I<must not> call C<ev_run> or similar functions that enter
2637the current event loop from either C<ev_prepare> or C<ev_check> 2736the current event loop from either C<ev_prepare> or C<ev_check>
2638watchers. Other loops than the current one are fine, however. The 2737watchers. Other loops than the current one are fine, however. The
2639rationale behind this is that you do not need to check for recursion in 2738rationale behind this is that you do not need to check for recursion in
2640those watchers, i.e. the sequence will always be C<ev_prepare>, blocking, 2739those watchers, i.e. the sequence will always be C<ev_prepare>, blocking,
2641C<ev_check> so if you have one watcher of each kind they will always be 2740C<ev_check> so if you have one watcher of each kind they will always be
2809 2908
2810 if (timeout >= 0) 2909 if (timeout >= 0)
2811 // create/start timer 2910 // create/start timer
2812 2911
2813 // poll 2912 // poll
2814 ev_loop (EV_A_ 0); 2913 ev_run (EV_A_ 0);
2815 2914
2816 // stop timer again 2915 // stop timer again
2817 if (timeout >= 0) 2916 if (timeout >= 0)
2818 ev_timer_stop (EV_A_ &to); 2917 ev_timer_stop (EV_A_ &to);
2819 2918
2897if you do not want that, you need to temporarily stop the embed watcher). 2996if you do not want that, you need to temporarily stop the embed watcher).
2898 2997
2899=item ev_embed_sweep (loop, ev_embed *) 2998=item ev_embed_sweep (loop, ev_embed *)
2900 2999
2901Make a single, non-blocking sweep over the embedded loop. This works 3000Make a single, non-blocking sweep over the embedded loop. This works
2902similarly to C<ev_loop (embedded_loop, EVLOOP_NONBLOCK)>, but in the most 3001similarly to C<ev_run (embedded_loop, EVRUN_NOWAIT)>, but in the most
2903appropriate way for embedded loops. 3002appropriate way for embedded loops.
2904 3003
2905=item struct ev_loop *other [read-only] 3004=item struct ev_loop *other [read-only]
2906 3005
2907The embedded event loop. 3006The embedded event loop.
2993disadvantage of having to use multiple event loops (which do not support 3092disadvantage of having to use multiple event loops (which do not support
2994signal watchers). 3093signal watchers).
2995 3094
2996When this is not possible, or you want to use the default loop for 3095When this is not possible, or you want to use the default loop for
2997other reasons, then in the process that wants to start "fresh", call 3096other reasons, then in the process that wants to start "fresh", call
2998C<ev_default_destroy ()> followed by C<ev_default_loop (...)>. Destroying 3097C<ev_loop_destroy (EV_DEFAULT)> followed by C<ev_default_loop (...)>.
2999the default loop will "orphan" (not stop) all registered watchers, so you 3098Destroying the default loop will "orphan" (not stop) all registered
3000have to be careful not to execute code that modifies those watchers. Note 3099watchers, so you have to be careful not to execute code that modifies
3001also that in that case, you have to re-register any signal watchers. 3100those watchers. Note also that in that case, you have to re-register any
3101signal watchers.
3002 3102
3003=head3 Watcher-Specific Functions and Data Members 3103=head3 Watcher-Specific Functions and Data Members
3004 3104
3005=over 4 3105=over 4
3006 3106
3007=item ev_fork_init (ev_signal *, callback) 3107=item ev_fork_init (ev_fork *, callback)
3008 3108
3009Initialises and configures the fork watcher - it has no parameters of any 3109Initialises and configures the fork watcher - it has no parameters of any
3010kind. There is a C<ev_fork_set> macro, but using it is utterly pointless, 3110kind. There is a C<ev_fork_set> macro, but using it is utterly pointless,
3011believe me. 3111really.
3012 3112
3013=back 3113=back
3014 3114
3015 3115
3116=head2 C<ev_cleanup> - even the best things end
3117
3118Cleanup watchers are called just before the event loop is being destroyed
3119by a call to C<ev_loop_destroy>.
3120
3121While there is no guarantee that the event loop gets destroyed, cleanup
3122watchers provide a convenient method to install cleanup hooks for your
3123program, worker threads and so on - you just to make sure to destroy the
3124loop when you want them to be invoked.
3125
3126Cleanup watchers are invoked in the same way as any other watcher. Unlike
3127all other watchers, they do not keep a reference to the event loop (which
3128makes a lot of sense if you think about it). Like all other watchers, you
3129can call libev functions in the callback, except C<ev_cleanup_start>.
3130
3131=head3 Watcher-Specific Functions and Data Members
3132
3133=over 4
3134
3135=item ev_cleanup_init (ev_cleanup *, callback)
3136
3137Initialises and configures the cleanup watcher - it has no parameters of
3138any kind. There is a C<ev_cleanup_set> macro, but using it is utterly
3139pointless, I assure you.
3140
3141=back
3142
3143Example: Register an atexit handler to destroy the default loop, so any
3144cleanup functions are called.
3145
3146 static void
3147 program_exits (void)
3148 {
3149 ev_loop_destroy (EV_DEFAULT_UC);
3150 }
3151
3152 ...
3153 atexit (program_exits);
3154
3155
3016=head2 C<ev_async> - how to wake up an event loop 3156=head2 C<ev_async> - how to wake up an event loop
3017 3157
3018In general, you cannot use an C<ev_loop> from multiple threads or other 3158In general, you cannot use an C<ev_run> from multiple threads or other
3019asynchronous sources such as signal handlers (as opposed to multiple event 3159asynchronous sources such as signal handlers (as opposed to multiple event
3020loops - those are of course safe to use in different threads). 3160loops - those are of course safe to use in different threads).
3021 3161
3022Sometimes, however, you need to wake up an event loop you do not control, 3162Sometimes, however, you need to wake up an event loop you do not control,
3023for example because it belongs to another thread. This is what C<ev_async> 3163for example because it belongs to another thread. This is what C<ev_async>
3530loop argument"). The C<EV_A> form is used when this is the sole argument, 3670loop argument"). The C<EV_A> form is used when this is the sole argument,
3531C<EV_A_> is used when other arguments are following. Example: 3671C<EV_A_> is used when other arguments are following. Example:
3532 3672
3533 ev_unref (EV_A); 3673 ev_unref (EV_A);
3534 ev_timer_add (EV_A_ watcher); 3674 ev_timer_add (EV_A_ watcher);
3535 ev_loop (EV_A_ 0); 3675 ev_run (EV_A_ 0);
3536 3676
3537It assumes the variable C<loop> of type C<struct ev_loop *> is in scope, 3677It assumes the variable C<loop> of type C<struct ev_loop *> is in scope,
3538which is often provided by the following macro. 3678which is often provided by the following macro.
3539 3679
3540=item C<EV_P>, C<EV_P_> 3680=item C<EV_P>, C<EV_P_>
3580 } 3720 }
3581 3721
3582 ev_check check; 3722 ev_check check;
3583 ev_check_init (&check, check_cb); 3723 ev_check_init (&check, check_cb);
3584 ev_check_start (EV_DEFAULT_ &check); 3724 ev_check_start (EV_DEFAULT_ &check);
3585 ev_loop (EV_DEFAULT_ 0); 3725 ev_run (EV_DEFAULT_ 0);
3586 3726
3587=head1 EMBEDDING 3727=head1 EMBEDDING
3588 3728
3589Libev can (and often is) directly embedded into host 3729Libev can (and often is) directly embedded into host
3590applications. Examples of applications that embed it include the Deliantra 3730applications. Examples of applications that embed it include the Deliantra
3681to a compiled library. All other symbols change the ABI, which means all 3821to a compiled library. All other symbols change the ABI, which means all
3682users of libev and the libev code itself must be compiled with compatible 3822users of libev and the libev code itself must be compiled with compatible
3683settings. 3823settings.
3684 3824
3685=over 4 3825=over 4
3826
3827=item EV_COMPAT3 (h)
3828
3829Backwards compatibility is a major concern for libev. This is why this
3830release of libev comes with wrappers for the functions and symbols that
3831have been renamed between libev version 3 and 4.
3832
3833You can disable these wrappers (to test compatibility with future
3834versions) by defining C<EV_COMPAT3> to C<0> when compiling your
3835sources. This has the additional advantage that you can drop the C<struct>
3836from C<struct ev_loop> declarations, as libev will provide an C<ev_loop>
3837typedef in that case.
3838
3839In some future version, the default for C<EV_COMPAT3> will become C<0>,
3840and in some even more future version the compatibility code will be
3841removed completely.
3686 3842
3687=item EV_STANDALONE (h) 3843=item EV_STANDALONE (h)
3688 3844
3689Must always be C<1> if you do not use autoconf configuration, which 3845Must always be C<1> if you do not use autoconf configuration, which
3690keeps libev from including F<config.h>, and it also defines dummy 3846keeps libev from including F<config.h>, and it also defines dummy
4265 userdata *u = ev_userdata (EV_A); 4421 userdata *u = ev_userdata (EV_A);
4266 pthread_mutex_lock (&u->lock); 4422 pthread_mutex_lock (&u->lock);
4267 } 4423 }
4268 4424
4269The event loop thread first acquires the mutex, and then jumps straight 4425The event loop thread first acquires the mutex, and then jumps straight
4270into C<ev_loop>: 4426into C<ev_run>:
4271 4427
4272 void * 4428 void *
4273 l_run (void *thr_arg) 4429 l_run (void *thr_arg)
4274 { 4430 {
4275 struct ev_loop *loop = (struct ev_loop *)thr_arg; 4431 struct ev_loop *loop = (struct ev_loop *)thr_arg;
4276 4432
4277 l_acquire (EV_A); 4433 l_acquire (EV_A);
4278 pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, 0); 4434 pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, 0);
4279 ev_loop (EV_A_ 0); 4435 ev_run (EV_A_ 0);
4280 l_release (EV_A); 4436 l_release (EV_A);
4281 4437
4282 return 0; 4438 return 0;
4283 } 4439 }
4284 4440
4336 4492
4337=head3 COROUTINES 4493=head3 COROUTINES
4338 4494
4339Libev is very accommodating to coroutines ("cooperative threads"): 4495Libev is very accommodating to coroutines ("cooperative threads"):
4340libev fully supports nesting calls to its functions from different 4496libev fully supports nesting calls to its functions from different
4341coroutines (e.g. you can call C<ev_loop> on the same loop from two 4497coroutines (e.g. you can call C<ev_run> on the same loop from two
4342different coroutines, and switch freely between both coroutines running 4498different coroutines, and switch freely between both coroutines running
4343the loop, as long as you don't confuse yourself). The only exception is 4499the loop, as long as you don't confuse yourself). The only exception is
4344that you must not do this from C<ev_periodic> reschedule callbacks. 4500that you must not do this from C<ev_periodic> reschedule callbacks.
4345 4501
4346Care has been taken to ensure that libev does not keep local state inside 4502Care has been taken to ensure that libev does not keep local state inside
4347C<ev_loop>, and other calls do not usually allow for coroutine switches as 4503C<ev_run>, and other calls do not usually allow for coroutine switches as
4348they do not call any callbacks. 4504they do not call any callbacks.
4349 4505
4350=head2 COMPILER WARNINGS 4506=head2 COMPILER WARNINGS
4351 4507
4352Depending on your compiler and compiler settings, you might get no or a 4508Depending on your compiler and compiler settings, you might get no or a
4436=head3 C<kqueue> is buggy 4592=head3 C<kqueue> is buggy
4437 4593
4438The kqueue syscall is broken in all known versions - most versions support 4594The kqueue syscall is broken in all known versions - most versions support
4439only sockets, many support pipes. 4595only sockets, many support pipes.
4440 4596
4441Libev tries to work around this by not using C<kqueue> by default on 4597Libev tries to work around this by not using C<kqueue> by default on this
4442this rotten platform, but of course you can still ask for it when creating 4598rotten platform, but of course you can still ask for it when creating a
4443a loop. 4599loop - embedding a socket-only kqueue loop into a select-based one is
4600probably going to work well.
4444 4601
4445=head3 C<poll> is buggy 4602=head3 C<poll> is buggy
4446 4603
4447Instead of fixing C<kqueue>, Apple replaced their (working) C<poll> 4604Instead of fixing C<kqueue>, Apple replaced their (working) C<poll>
4448implementation by something calling C<kqueue> internally around the 10.5.6 4605implementation by something calling C<kqueue> internally around the 10.5.6
4467 4624
4468=head3 C<errno> reentrancy 4625=head3 C<errno> reentrancy
4469 4626
4470The default compile environment on Solaris is unfortunately so 4627The default compile environment on Solaris is unfortunately so
4471thread-unsafe that you can't even use components/libraries compiled 4628thread-unsafe that you can't even use components/libraries compiled
4472without C<-D_REENTRANT> (as long as they use C<errno>), which, of course, 4629without C<-D_REENTRANT> in a threaded program, which, of course, isn't
4473isn't defined by default. 4630defined by default. A valid, if stupid, implementation choice.
4474 4631
4475If you want to use libev in threaded environments you have to make sure 4632If you want to use libev in threaded environments you have to make sure
4476it's compiled with C<_REENTRANT> defined. 4633it's compiled with C<_REENTRANT> defined.
4477 4634
4478=head3 Event port backend 4635=head3 Event port backend
4479 4636
4480The scalable event interface for Solaris is called "event ports". Unfortunately, 4637The scalable event interface for Solaris is called "event
4481this mechanism is very buggy. If you run into high CPU usage, your program 4638ports". Unfortunately, this mechanism is very buggy in all major
4639releases. If you run into high CPU usage, your program freezes or you get
4482freezes or you get a large number of spurious wakeups, make sure you have 4640a large number of spurious wakeups, make sure you have all the relevant
4483all the relevant and latest kernel patches applied. No, I don't know which 4641and latest kernel patches applied. No, I don't know which ones, but there
4484ones, but there are multiple ones. 4642are multiple ones to apply, and afterwards, event ports actually work
4643great.
4485 4644
4486If you can't get it to work, you can try running the program by setting 4645If you can't get it to work, you can try running the program by setting
4487the environment variable C<LIBEV_FLAGS=3> to only allow C<poll> and 4646the environment variable C<LIBEV_FLAGS=3> to only allow C<poll> and
4488C<select> backends. 4647C<select> backends.
4489 4648
4490=head2 AIX POLL BUG 4649=head2 AIX POLL BUG
4491 4650
4492AIX unfortunately has a broken C<poll.h> header. Libev works around 4651AIX unfortunately has a broken C<poll.h> header. Libev works around
4493this by trying to avoid the poll backend altogether (i.e. it's not even 4652this by trying to avoid the poll backend altogether (i.e. it's not even
4494compiled in), which normally isn't a big problem as C<select> works fine 4653compiled in), which normally isn't a big problem as C<select> works fine
4495with large bitsets, and AIX is dead anyway. 4654with large bitsets on AIX, and AIX is dead anyway.
4496 4655
4497=head2 WIN32 PLATFORM LIMITATIONS AND WORKAROUNDS 4656=head2 WIN32 PLATFORM LIMITATIONS AND WORKAROUNDS
4498 4657
4499=head3 General issues 4658=head3 General issues
4500 4659
4606structure (guaranteed by POSIX but not by ISO C for example), but it also 4765structure (guaranteed by POSIX but not by ISO C for example), but it also
4607assumes that the same (machine) code can be used to call any watcher 4766assumes that the same (machine) code can be used to call any watcher
4608callback: The watcher callbacks have different type signatures, but libev 4767callback: The watcher callbacks have different type signatures, but libev
4609calls them using an C<ev_watcher *> internally. 4768calls them using an C<ev_watcher *> internally.
4610 4769
4770=item pointer accesses must be thread-atomic
4771
4772Accessing a pointer value must be atomic, it must both be readable and
4773writable in one piece - this is the case on all current architectures.
4774
4611=item C<sig_atomic_t volatile> must be thread-atomic as well 4775=item C<sig_atomic_t volatile> must be thread-atomic as well
4612 4776
4613The type C<sig_atomic_t volatile> (or whatever is defined as 4777The type C<sig_atomic_t volatile> (or whatever is defined as
4614C<EV_ATOMIC_T>) must be atomic with respect to accesses from different 4778C<EV_ATOMIC_T>) must be atomic with respect to accesses from different
4615threads. This is not part of the specification for C<sig_atomic_t>, but is 4779threads. This is not part of the specification for C<sig_atomic_t>, but is
4721=back 4885=back
4722 4886
4723 4887
4724=head1 PORTING FROM LIBEV 3.X TO 4.X 4888=head1 PORTING FROM LIBEV 3.X TO 4.X
4725 4889
4726The major version 4 introduced some minor incompatible changes to the API. 4890The major version 4 introduced some incompatible changes to the API.
4727 4891
4728At the moment, the C<ev.h> header file tries to implement superficial 4892At the moment, the C<ev.h> header file provides compatibility definitions
4729compatibility, so most programs should still compile. Those might be 4893for all changes, so most programs should still compile. The compatibility
4730removed in later versions of libev, so better update early than late. 4894layer might be removed in later versions of libev, so better update to the
4895new API early than late.
4731 4896
4732=over 4 4897=over 4
4733 4898
4734=item C<ev_loop_count> renamed to C<ev_iteration> 4899=item C<EV_COMPAT3> backwards compatibility mechanism
4735 4900
4736=item C<ev_loop_depth> renamed to C<ev_depth> 4901The backward compatibility mechanism can be controlled by
4902C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING>
4903section.
4737 4904
4738=item C<ev_loop_verify> renamed to C<ev_verify> 4905=item C<ev_default_destroy> and C<ev_default_fork> have been removed
4906
4907These calls can be replaced easily by their C<ev_loop_xxx> counterparts:
4908
4909 ev_loop_destroy (EV_DEFAULT_UC);
4910 ev_loop_fork (EV_DEFAULT);
4911
4912=item function/symbol renames
4913
4914A number of functions and symbols have been renamed:
4915
4916 ev_loop => ev_run
4917 EVLOOP_NONBLOCK => EVRUN_NOWAIT
4918 EVLOOP_ONESHOT => EVRUN_ONCE
4919
4920 ev_unloop => ev_break
4921 EVUNLOOP_CANCEL => EVBREAK_CANCEL
4922 EVUNLOOP_ONE => EVBREAK_ONE
4923 EVUNLOOP_ALL => EVBREAK_ALL
4924
4925 EV_TIMEOUT => EV_TIMER
4926
4927 ev_loop_count => ev_iteration
4928 ev_loop_depth => ev_depth
4929 ev_loop_verify => ev_verify
4739 4930
4740Most functions working on C<struct ev_loop> objects don't have an 4931Most functions working on C<struct ev_loop> objects don't have an
4741C<ev_loop_> prefix, so it was removed. Note that C<ev_loop_fork> is 4932C<ev_loop_> prefix, so it was removed; C<ev_loop>, C<ev_unloop> and
4933associated constants have been renamed to not collide with the C<struct
4934ev_loop> anymore and C<EV_TIMER> now follows the same naming scheme
4935as all other watcher types. Note that C<ev_loop_fork> is still called
4742still called C<ev_loop_fork> because it would otherwise clash with the 4936C<ev_loop_fork> because it would otherwise clash with the C<ev_fork>
4743C<ev_fork> typedef. 4937typedef.
4744
4745=item C<EV_TIMEOUT> renamed to C<EV_TIMER> in C<revents>
4746
4747This is a simple rename - all other watcher types use their name
4748as revents flag, and now C<ev_timer> does, too.
4749
4750Both C<EV_TIMER> and C<EV_TIMEOUT> symbols were present in 3.x versions
4751and continue to be present for the foreseeable future, so this is mostly a
4752documentation change.
4753 4938
4754=item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES> 4939=item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
4755 4940
4756The preprocessor symbol C<EV_MINIMAL> has been replaced by a different 4941The preprocessor symbol C<EV_MINIMAL> has been replaced by a different
4757mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile 4942mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile
4764 4949
4765=over 4 4950=over 4
4766 4951
4767=item active 4952=item active
4768 4953
4769A watcher is active as long as it has been started (has been attached to 4954A watcher is active as long as it has been started and not yet stopped.
4770an event loop) but not yet stopped (disassociated from the event loop). 4955See L<WATCHER STATES> for details.
4771 4956
4772=item application 4957=item application
4773 4958
4774In this document, an application is whatever is using libev. 4959In this document, an application is whatever is using libev.
4960
4961=item backend
4962
4963The part of the code dealing with the operating system interfaces.
4775 4964
4776=item callback 4965=item callback
4777 4966
4778The address of a function that is called when some event has been 4967The address of a function that is called when some event has been
4779detected. Callbacks are being passed the event loop, the watcher that 4968detected. Callbacks are being passed the event loop, the watcher that
4780received the event, and the actual event bitset. 4969received the event, and the actual event bitset.
4781 4970
4782=item callback invocation 4971=item callback/watcher invocation
4783 4972
4784The act of calling the callback associated with a watcher. 4973The act of calling the callback associated with a watcher.
4785 4974
4786=item event 4975=item event
4787 4976
4806The model used to describe how an event loop handles and processes 4995The model used to describe how an event loop handles and processes
4807watchers and events. 4996watchers and events.
4808 4997
4809=item pending 4998=item pending
4810 4999
4811A watcher is pending as soon as the corresponding event has been detected, 5000A watcher is pending as soon as the corresponding event has been
4812and stops being pending as soon as the watcher will be invoked or its 5001detected. See L<WATCHER STATES> for details.
4813pending status is explicitly cleared by the application.
4814
4815A watcher can be pending, but not active. Stopping a watcher also clears
4816its pending status.
4817 5002
4818=item real time 5003=item real time
4819 5004
4820The physical time that is observed. It is apparently strictly monotonic :) 5005The physical time that is observed. It is apparently strictly monotonic :)
4821 5006
4828=item watcher 5013=item watcher
4829 5014
4830A data structure that describes interest in certain events. Watchers need 5015A data structure that describes interest in certain events. Watchers need
4831to be started (attached to an event loop) before they can receive events. 5016to be started (attached to an event loop) before they can receive events.
4832 5017
4833=item watcher invocation
4834
4835The act of calling the callback associated with a watcher.
4836
4837=back 5018=back
4838 5019
4839=head1 AUTHOR 5020=head1 AUTHOR
4840 5021
4841Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson. 5022Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael
5023Magnusson and Emanuele Giaquinta.
4842 5024

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines