… | |
… | |
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 Inotify |
|
|
1502 | |
|
|
1503 | When C<inotify (7)> support has been compiled into libev (generally only |
|
|
1504 | available on Linux) and present at runtime, it will be used to speed up |
|
|
1505 | change detection where possible. The inotify descriptor will be created lazily |
|
|
1506 | when the first C<ev_stat> watcher is being started. |
|
|
1507 | |
|
|
1508 | Inotify presense does not change the semantics of C<ev_stat> watchers |
|
|
1509 | except that changes might be detected earlier, and in some cases, to avoid |
|
|
1510 | making regular C<stat> calls. Even in the presense of inotify support |
|
|
1511 | there are many cases where libev has to resort to regular C<stat> polling. |
|
|
1512 | |
|
|
1513 | (There is no support for kqueue, as apparently it cannot be used to |
|
|
1514 | implement this functionality, due to the requirement of having a file |
|
|
1515 | descriptor open on the object at all times). |
|
|
1516 | |
|
|
1517 | =head3 The special problem of stat time resolution |
|
|
1518 | |
|
|
1519 | The C<stat ()> syscall only supports full-second resolution portably, and |
|
|
1520 | even on systems where the resolution is higher, many filesystems still |
|
|
1521 | only support whole seconds. |
|
|
1522 | |
|
|
1523 | That means that, if the time is the only thing that changes, you might |
|
|
1524 | miss updates: on the first update, C<ev_stat> detects a change and calls |
|
|
1525 | your callback, which does something. When there is another update within |
|
|
1526 | the same second, C<ev_stat> will be unable to detect it. |
|
|
1527 | |
|
|
1528 | The solution to this is to delay acting on a change for a second (or till |
|
|
1529 | the next second boundary), using a roughly one-second delay C<ev_timer> |
|
|
1530 | (C<ev_timer_set (w, 0., 1.01); ev_timer_again (loop, w)>). The C<.01> |
|
|
1531 | is added to work around small timing inconsistencies of some operating |
|
|
1532 | systems. |
|
|
1533 | |
1501 | =head3 Watcher-Specific Functions and Data Members |
1534 | =head3 Watcher-Specific Functions and Data Members |
1502 | |
1535 | |
1503 | =over 4 |
1536 | =over 4 |
1504 | |
1537 | |
1505 | =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval) |
1538 | =item ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval) |
… | |
… | |
1542 | =item const char *path [read-only] |
1575 | =item const char *path [read-only] |
1543 | |
1576 | |
1544 | The filesystem path that is being watched. |
1577 | The filesystem path that is being watched. |
1545 | |
1578 | |
1546 | =back |
1579 | =back |
|
|
1580 | |
|
|
1581 | =head3 Examples |
1547 | |
1582 | |
1548 | Example: Watch C</etc/passwd> for attribute changes. |
1583 | Example: Watch C</etc/passwd> for attribute changes. |
1549 | |
1584 | |
1550 | static void |
1585 | static void |
1551 | passwd_cb (struct ev_loop *loop, ev_stat *w, int revents) |
1586 | passwd_cb (struct ev_loop *loop, ev_stat *w, int revents) |
… | |
… | |
1564 | } |
1599 | } |
1565 | |
1600 | |
1566 | ... |
1601 | ... |
1567 | ev_stat passwd; |
1602 | ev_stat passwd; |
1568 | |
1603 | |
1569 | ev_stat_init (&passwd, passwd_cb, "/etc/passwd"); |
1604 | ev_stat_init (&passwd, passwd_cb, "/etc/passwd", 0.); |
1570 | ev_stat_start (loop, &passwd); |
1605 | ev_stat_start (loop, &passwd); |
|
|
1606 | |
|
|
1607 | Example: Like above, but additionally use a one-second delay so we do not |
|
|
1608 | miss updates (however, frequent updates will delay processing, too, so |
|
|
1609 | one might do the work both on C<ev_stat> callback invocation I<and> on |
|
|
1610 | C<ev_timer> callback invocation). |
|
|
1611 | |
|
|
1612 | static ev_stat passwd; |
|
|
1613 | static ev_timer timer; |
|
|
1614 | |
|
|
1615 | static void |
|
|
1616 | timer_cb (EV_P_ ev_timer *w, int revents) |
|
|
1617 | { |
|
|
1618 | ev_timer_stop (EV_A_ w); |
|
|
1619 | |
|
|
1620 | /* now it's one second after the most recent passwd change */ |
|
|
1621 | } |
|
|
1622 | |
|
|
1623 | static void |
|
|
1624 | stat_cb (EV_P_ ev_stat *w, int revents) |
|
|
1625 | { |
|
|
1626 | /* reset the one-second timer */ |
|
|
1627 | ev_timer_again (EV_A_ &timer); |
|
|
1628 | } |
|
|
1629 | |
|
|
1630 | ... |
|
|
1631 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
|
|
1632 | ev_stat_start (loop, &passwd); |
|
|
1633 | ev_timer_init (&timer, timer_cb, 0., 1.01); |
1571 | |
1634 | |
1572 | |
1635 | |
1573 | =head2 C<ev_idle> - when you've got nothing better to do... |
1636 | =head2 C<ev_idle> - when you've got nothing better to do... |
1574 | |
1637 | |
1575 | Idle watchers trigger events when no other events of the same or higher |
1638 | Idle watchers trigger events when no other events of the same or higher |
… | |
… | |
2632 | |
2695 | |
2633 | =item Starting and stopping timer/periodic watchers: O(log skipped_other_timers) |
2696 | =item Starting and stopping timer/periodic watchers: O(log skipped_other_timers) |
2634 | |
2697 | |
2635 | This means that, when you have a watcher that triggers in one hour and |
2698 | 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 |
2699 | there are 100 watchers that would trigger before that then inserting will |
2637 | have to skip those 100 watchers. |
2700 | have to skip roughly seven (C<ld 100>) of these watchers. |
2638 | |
2701 | |
2639 | =item Changing timer/periodic watchers (by autorepeat, again): O(log skipped_other_timers) |
2702 | =item Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers) |
2640 | |
2703 | |
2641 | That means that for changing a timer costs less than removing/adding them |
2704 | 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. |
2705 | as only the relative motion in the event queue has to be paid for. |
2643 | |
2706 | |
2644 | =item Starting io/check/prepare/idle/signal/child watchers: O(1) |
2707 | =item Starting io/check/prepare/idle/signal/child watchers: O(1) |
2645 | |
2708 | |
2646 | These just add the watcher into an array or at the head of a list. |
2709 | These just add the watcher into an array or at the head of a list. |
|
|
2710 | |
2647 | =item Stopping check/prepare/idle watchers: O(1) |
2711 | =item Stopping check/prepare/idle watchers: O(1) |
2648 | |
2712 | |
2649 | =item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE)) |
2713 | =item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE)) |
2650 | |
2714 | |
2651 | These watchers are stored in lists then need to be walked to find the |
2715 | 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 |
2716 | correct watcher to remove. The lists are usually short (you don't usually |
2653 | have many watchers waiting for the same fd or signal). |
2717 | have many watchers waiting for the same fd or signal). |
2654 | |
2718 | |
2655 | =item Finding the next timer per loop iteration: O(1) |
2719 | =item Finding the next timer in each loop iteration: O(1) |
|
|
2720 | |
|
|
2721 | By virtue of using a binary heap, the next timer is always found at the |
|
|
2722 | beginning of the storage array. |
2656 | |
2723 | |
2657 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
2724 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
2658 | |
2725 | |
2659 | A change means an I/O watcher gets started or stopped, which requires |
2726 | A change means an I/O watcher gets started or stopped, which requires |
2660 | libev to recalculate its status (and possibly tell the kernel). |
2727 | libev to recalculate its status (and possibly tell the kernel, depending |
|
|
2728 | on backend and wether C<ev_io_set> was used). |
2661 | |
2729 | |
2662 | =item Activating one watcher: O(1) |
2730 | =item Activating one watcher (putting it into the pending state): O(1) |
2663 | |
2731 | |
2664 | =item Priority handling: O(number_of_priorities) |
2732 | =item Priority handling: O(number_of_priorities) |
2665 | |
2733 | |
2666 | Priorities are implemented by allocating some space for each |
2734 | Priorities are implemented by allocating some space for each |
2667 | priority. When doing priority-based operations, libev usually has to |
2735 | priority. When doing priority-based operations, libev usually has to |
2668 | linearly search all the priorities. |
2736 | linearly search all the priorities, but starting/stopping and activating |
|
|
2737 | watchers becomes O(1) w.r.t. prioritiy handling. |
2669 | |
2738 | |
2670 | =back |
2739 | =back |
2671 | |
2740 | |
2672 | |
2741 | |
2673 | =head1 AUTHOR |
2742 | =head1 AUTHOR |