… | |
… | |
4 | |
4 | |
5 | =head1 SYNOPSIS |
5 | =head1 SYNOPSIS |
6 | |
6 | |
7 | #include <ev.h> |
7 | #include <ev.h> |
8 | |
8 | |
9 | =head1 EXAMPLE PROGRAM |
9 | =head2 EXAMPLE PROGRAM |
10 | |
10 | |
11 | #include <ev.h> |
11 | #include <ev.h> |
12 | |
12 | |
13 | ev_io stdin_watcher; |
13 | ev_io stdin_watcher; |
14 | ev_timer timeout_watcher; |
14 | ev_timer timeout_watcher; |
… | |
… | |
65 | You register interest in certain events by registering so-called I<event |
65 | You register interest in certain events by registering so-called I<event |
66 | watchers>, which are relatively small C structures you initialise with the |
66 | watchers>, which are relatively small C structures you initialise with the |
67 | details of the event, and then hand it over to libev by I<starting> the |
67 | details of the event, and then hand it over to libev by I<starting> the |
68 | watcher. |
68 | watcher. |
69 | |
69 | |
70 | =head1 FEATURES |
70 | =head2 FEATURES |
71 | |
71 | |
72 | Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the |
72 | Libev supports C<select>, C<poll>, the Linux-specific C<epoll>, the |
73 | BSD-specific C<kqueue> and the Solaris-specific event port mechanisms |
73 | BSD-specific C<kqueue> and the Solaris-specific event port mechanisms |
74 | for file descriptor events (C<ev_io>), the Linux C<inotify> interface |
74 | for file descriptor events (C<ev_io>), the Linux C<inotify> interface |
75 | (for C<ev_stat>), relative timers (C<ev_timer>), absolute timers |
75 | (for C<ev_stat>), relative timers (C<ev_timer>), absolute timers |
… | |
… | |
82 | |
82 | |
83 | It also is quite fast (see this |
83 | It also is quite fast (see this |
84 | L<benchmark|http://libev.schmorp.de/bench.html> comparing it to libevent |
84 | L<benchmark|http://libev.schmorp.de/bench.html> comparing it to libevent |
85 | for example). |
85 | for example). |
86 | |
86 | |
87 | =head1 CONVENTIONS |
87 | =head2 CONVENTIONS |
88 | |
88 | |
89 | Libev is very configurable. In this manual the default configuration will |
89 | Libev is very configurable. In this manual the default configuration will |
90 | be described, which supports multiple event loops. For more info about |
90 | be described, which supports multiple event loops. For more info about |
91 | various configuration options please have a look at B<EMBED> section in |
91 | various configuration options please have a look at B<EMBED> section in |
92 | this manual. If libev was configured without support for multiple event |
92 | this manual. If libev was configured without support for multiple event |
93 | loops, then all functions taking an initial argument of name C<loop> |
93 | loops, then all functions taking an initial argument of name C<loop> |
94 | (which is always of type C<struct ev_loop *>) will not have this argument. |
94 | (which is always of type C<struct ev_loop *>) will not have this argument. |
95 | |
95 | |
96 | =head1 TIME REPRESENTATION |
96 | =head2 TIME REPRESENTATION |
97 | |
97 | |
98 | Libev represents time as a single floating point number, representing the |
98 | Libev represents time as a single floating point number, representing the |
99 | (fractional) number of seconds since the (POSIX) epoch (somewhere near |
99 | (fractional) number of seconds since the (POSIX) epoch (somewhere near |
100 | the beginning of 1970, details are complicated, don't ask). This type is |
100 | the beginning of 1970, details are complicated, don't ask). This type is |
101 | called C<ev_tstamp>, which is what you should use too. It usually aliases |
101 | called C<ev_tstamp>, which is what you should use too. It usually aliases |
… | |
… | |
1496 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1496 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1497 | to fall back to regular polling again even with inotify, but changes are |
1497 | to fall back to regular polling again even with inotify, but changes are |
1498 | usually detected immediately, and if the file exists there will be no |
1498 | usually detected immediately, and if the file exists there will be no |
1499 | polling. |
1499 | polling. |
1500 | |
1500 | |
|
|
1501 | =head3 The special problem of stat time resolution |
|
|
1502 | |
|
|
1503 | The C<stat ()> syscall only supports full-second resolution portably, and |
|
|
1504 | even on systems where the resolution is higher, many filesystems still |
|
|
1505 | only support whole seconds. |
|
|
1506 | |
|
|
1507 | That means that, if the time is the only thing that changes, you might |
|
|
1508 | miss updates: on the first update, C<ev_stat> detects a change and calls |
|
|
1509 | your callback, which does something. When there is another update within |
|
|
1510 | the same second, C<ev_stat> will be unable to detect it. |
|
|
1511 | |
|
|
1512 | The solution to this is to delay acting on a change for a second (or till |
|
|
1513 | the next second boundary), using a roughly one-second delay C<ev_timer> |
|
|
1514 | (C<ev_timer_set (w, 0., 1.01); ev_timer_again (loop, w)>). The C<.01> |
|
|
1515 | is added to work around small timing inconsistencies of some operating |
|
|
1516 | systems. |
|
|
1517 | |
1501 | =head3 Watcher-Specific Functions and Data Members |
1518 | =head3 Watcher-Specific Functions and Data Members |
1502 | |
1519 | |
1503 | =over 4 |
1520 | =over 4 |
1504 | |
1521 | |
1505 | =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval) |
1522 | =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval) |
… | |
… | |
1564 | } |
1581 | } |
1565 | |
1582 | |
1566 | ... |
1583 | ... |
1567 | ev_stat passwd; |
1584 | ev_stat passwd; |
1568 | |
1585 | |
1569 | ev_stat_init (&passwd, passwd_cb, "/etc/passwd"); |
1586 | ev_stat_init (&passwd, passwd_cb, "/etc/passwd", 0.); |
1570 | ev_stat_start (loop, &passwd); |
1587 | ev_stat_start (loop, &passwd); |
|
|
1588 | |
|
|
1589 | Example: Like above, but additionally use a one-second delay so we do not |
|
|
1590 | miss updates (however, frequent updates will delay processing, too, so |
|
|
1591 | one might do the work both on C<ev_stat> callback invocation I<and> on |
|
|
1592 | C<ev_timer> callback invocation). |
|
|
1593 | |
|
|
1594 | static ev_stat passwd; |
|
|
1595 | static ev_timer timer; |
|
|
1596 | |
|
|
1597 | static void |
|
|
1598 | timer_cb (EV_P_ ev_timer *w, int revents) |
|
|
1599 | { |
|
|
1600 | ev_timer_stop (EV_A_ w); |
|
|
1601 | |
|
|
1602 | /* now it's one second after the most recent passwd change */ |
|
|
1603 | } |
|
|
1604 | |
|
|
1605 | static void |
|
|
1606 | stat_cb (EV_P_ ev_stat *w, int revents) |
|
|
1607 | { |
|
|
1608 | /* reset the one-second timer */ |
|
|
1609 | ev_timer_again (EV_A_ &timer); |
|
|
1610 | } |
|
|
1611 | |
|
|
1612 | ... |
|
|
1613 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
|
|
1614 | ev_stat_start (loop, &passwd); |
|
|
1615 | ev_timer_init (&timer, timer_cb, 0., 1.01); |
1571 | |
1616 | |
1572 | |
1617 | |
1573 | =head2 C<ev_idle> - when you've got nothing better to do... |
1618 | =head2 C<ev_idle> - when you've got nothing better to do... |
1574 | |
1619 | |
1575 | Idle watchers trigger events when no other events of the same or higher |
1620 | Idle watchers trigger events when no other events of the same or higher |
… | |
… | |
2526 | than enough. If you need to manage thousands of children you might want to |
2571 | than enough. If you need to manage thousands of children you might want to |
2527 | increase this value (I<must> be a power of two). |
2572 | increase this value (I<must> be a power of two). |
2528 | |
2573 | |
2529 | =item EV_INOTIFY_HASHSIZE |
2574 | =item EV_INOTIFY_HASHSIZE |
2530 | |
2575 | |
2531 | C<ev_staz> watchers use a small hash table to distribute workload by |
2576 | C<ev_stat> watchers use a small hash table to distribute workload by |
2532 | inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>), |
2577 | inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>), |
2533 | usually more than enough. If you need to manage thousands of C<ev_stat> |
2578 | usually more than enough. If you need to manage thousands of C<ev_stat> |
2534 | watchers you might want to increase this value (I<must> be a power of |
2579 | watchers you might want to increase this value (I<must> be a power of |
2535 | two). |
2580 | two). |
2536 | |
2581 | |
… | |
… | |
2632 | |
2677 | |
2633 | =item Starting and stopping timer/periodic watchers: O(log skipped_other_timers) |
2678 | =item Starting and stopping timer/periodic watchers: O(log skipped_other_timers) |
2634 | |
2679 | |
2635 | This means that, when you have a watcher that triggers in one hour and |
2680 | This means that, when you have a watcher that triggers in one hour and |
2636 | there are 100 watchers that would trigger before that then inserting will |
2681 | there are 100 watchers that would trigger before that then inserting will |
2637 | have to skip those 100 watchers. |
2682 | have to skip roughly seven (C<ld 100>) of these watchers. |
2638 | |
2683 | |
2639 | =item Changing timer/periodic watchers (by autorepeat, again): O(log skipped_other_timers) |
2684 | =item Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers) |
2640 | |
2685 | |
2641 | That means that for changing a timer costs less than removing/adding them |
2686 | That means that changing a timer costs less than removing/adding them |
2642 | as only the relative motion in the event queue has to be paid for. |
2687 | as only the relative motion in the event queue has to be paid for. |
2643 | |
2688 | |
2644 | =item Starting io/check/prepare/idle/signal/child watchers: O(1) |
2689 | =item Starting io/check/prepare/idle/signal/child watchers: O(1) |
2645 | |
2690 | |
2646 | These just add the watcher into an array or at the head of a list. |
2691 | These just add the watcher into an array or at the head of a list. |
|
|
2692 | |
2647 | =item Stopping check/prepare/idle watchers: O(1) |
2693 | =item Stopping check/prepare/idle watchers: O(1) |
2648 | |
2694 | |
2649 | =item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE)) |
2695 | =item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE)) |
2650 | |
2696 | |
2651 | These watchers are stored in lists then need to be walked to find the |
2697 | These watchers are stored in lists then need to be walked to find the |
2652 | correct watcher to remove. The lists are usually short (you don't usually |
2698 | correct watcher to remove. The lists are usually short (you don't usually |
2653 | have many watchers waiting for the same fd or signal). |
2699 | have many watchers waiting for the same fd or signal). |
2654 | |
2700 | |
2655 | =item Finding the next timer per loop iteration: O(1) |
2701 | =item Finding the next timer in each loop iteration: O(1) |
|
|
2702 | |
|
|
2703 | By virtue of using a binary heap, the next timer is always found at the |
|
|
2704 | beginning of the storage array. |
2656 | |
2705 | |
2657 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
2706 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
2658 | |
2707 | |
2659 | A change means an I/O watcher gets started or stopped, which requires |
2708 | A change means an I/O watcher gets started or stopped, which requires |
2660 | libev to recalculate its status (and possibly tell the kernel). |
2709 | libev to recalculate its status (and possibly tell the kernel, depending |
|
|
2710 | on backend and wether C<ev_io_set> was used). |
2661 | |
2711 | |
2662 | =item Activating one watcher: O(1) |
2712 | =item Activating one watcher (putting it into the pending state): O(1) |
2663 | |
2713 | |
2664 | =item Priority handling: O(number_of_priorities) |
2714 | =item Priority handling: O(number_of_priorities) |
2665 | |
2715 | |
2666 | Priorities are implemented by allocating some space for each |
2716 | Priorities are implemented by allocating some space for each |
2667 | priority. When doing priority-based operations, libev usually has to |
2717 | priority. When doing priority-based operations, libev usually has to |
2668 | linearly search all the priorities. |
2718 | linearly search all the priorities, but starting/stopping and activating |
|
|
2719 | watchers becomes O(1) w.r.t. prioritiy handling. |
2669 | |
2720 | |
2670 | =back |
2721 | =back |
2671 | |
2722 | |
2672 | |
2723 | |
2673 | =head1 AUTHOR |
2724 | =head1 AUTHOR |