… | |
… | |
196 | See the description of C<ev_embed> watchers for more info. |
196 | See the description of C<ev_embed> watchers for more info. |
197 | |
197 | |
198 | =item ev_set_allocator (void *(*cb)(void *ptr, long size)) |
198 | =item ev_set_allocator (void *(*cb)(void *ptr, long size)) |
199 | |
199 | |
200 | Sets the allocation function to use (the prototype is similar - the |
200 | Sets the allocation function to use (the prototype is similar - the |
201 | semantics is identical - to the realloc C function). It is used to |
201 | semantics are identical to the C<realloc> C89/SuS/POSIX function). It is |
202 | allocate and free memory (no surprises here). If it returns zero when |
202 | used to allocate and free memory (no surprises here). If it returns zero |
203 | memory needs to be allocated, the library might abort or take some |
203 | when memory needs to be allocated (C<size != 0>), the library might abort |
204 | potentially destructive action. The default is your system realloc |
204 | or take some potentially destructive action. |
205 | function. |
205 | |
|
|
206 | Since some systems (at least OpenBSD and Darwin) fail to implement |
|
|
207 | correct C<realloc> semantics, libev will use a wrapper around the system |
|
|
208 | C<realloc> and C<free> functions by default. |
206 | |
209 | |
207 | You could override this function in high-availability programs to, say, |
210 | You could override this function in high-availability programs to, say, |
208 | free some memory if it cannot allocate memory, to use a special allocator, |
211 | free some memory if it cannot allocate memory, to use a special allocator, |
209 | or even to sleep a while and retry until some memory is available. |
212 | or even to sleep a while and retry until some memory is available. |
210 | |
213 | |
211 | Example: Replace the libev allocator with one that waits a bit and then |
214 | Example: Replace the libev allocator with one that waits a bit and then |
212 | retries). |
215 | retries (example requires a standards-compliant C<realloc>). |
213 | |
216 | |
214 | static void * |
217 | static void * |
215 | persistent_realloc (void *ptr, size_t size) |
218 | persistent_realloc (void *ptr, size_t size) |
216 | { |
219 | { |
217 | for (;;) |
220 | for (;;) |
… | |
… | |
256 | |
259 | |
257 | An event loop is described by a C<struct ev_loop *>. The library knows two |
260 | An event loop is described by a C<struct ev_loop *>. The library knows two |
258 | types of such loops, the I<default> loop, which supports signals and child |
261 | types of such loops, the I<default> loop, which supports signals and child |
259 | events, and dynamically created loops which do not. |
262 | events, and dynamically created loops which do not. |
260 | |
263 | |
261 | If you use threads, a common model is to run the default event loop |
|
|
262 | in your main thread (or in a separate thread) and for each thread you |
|
|
263 | create, you also create another event loop. Libev itself does no locking |
|
|
264 | whatsoever, so if you mix calls to the same event loop in different |
|
|
265 | threads, make sure you lock (this is usually a bad idea, though, even if |
|
|
266 | done correctly, because it's hideous and inefficient). |
|
|
267 | |
|
|
268 | =over 4 |
264 | =over 4 |
269 | |
265 | |
270 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
266 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
271 | |
267 | |
272 | This will initialise the default event loop if it hasn't been initialised |
268 | This will initialise the default event loop if it hasn't been initialised |
… | |
… | |
274 | false. If it already was initialised it simply returns it (and ignores the |
270 | false. If it already was initialised it simply returns it (and ignores the |
275 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
271 | flags. If that is troubling you, check C<ev_backend ()> afterwards). |
276 | |
272 | |
277 | If you don't know what event loop to use, use the one returned from this |
273 | If you don't know what event loop to use, use the one returned from this |
278 | function. |
274 | function. |
|
|
275 | |
|
|
276 | Note that this function is I<not> thread-safe, so if you want to use it |
|
|
277 | from multiple threads, you have to lock (note also that this is unlikely, |
|
|
278 | as loops cannot bes hared easily between threads anyway). |
279 | |
279 | |
280 | The default loop is the only loop that can handle C<ev_signal> and |
280 | The default loop is the only loop that can handle C<ev_signal> and |
281 | C<ev_child> watchers, and to do this, it always registers a handler |
281 | C<ev_child> watchers, and to do this, it always registers a handler |
282 | for C<SIGCHLD>. If this is a problem for your app you can either |
282 | for C<SIGCHLD>. If this is a problem for your app you can either |
283 | create a dynamic loop with C<ev_loop_new> that doesn't do that, or you |
283 | create a dynamic loop with C<ev_loop_new> that doesn't do that, or you |
… | |
… | |
354 | For few fds, this backend is a bit little slower than poll and select, |
354 | For few fds, this backend is a bit little slower than poll and select, |
355 | but it scales phenomenally better. While poll and select usually scale |
355 | but it scales phenomenally better. While poll and select usually scale |
356 | like O(total_fds) where n is the total number of fds (or the highest fd), |
356 | like O(total_fds) where n is the total number of fds (or the highest fd), |
357 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
357 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
358 | of shortcomings, such as silently dropping events in some hard-to-detect |
358 | of shortcomings, such as silently dropping events in some hard-to-detect |
359 | cases and rewiring a syscall per fd change, no fork support and bad |
359 | cases and requiring a syscall per fd change, no fork support and bad |
360 | support for dup. |
360 | support for dup. |
361 | |
361 | |
362 | While stopping, setting and starting an I/O watcher in the same iteration |
362 | While stopping, setting and starting an I/O watcher in the same iteration |
363 | will result in some caching, there is still a syscall per such incident |
363 | will result in some caching, there is still a syscall per such incident |
364 | (because the fd could point to a different file description now), so its |
364 | (because the fd could point to a different file description now), so its |
… | |
… | |
465 | |
465 | |
466 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
466 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
467 | always distinct from the default loop. Unlike the default loop, it cannot |
467 | always distinct from the default loop. Unlike the default loop, it cannot |
468 | handle signal and child watchers, and attempts to do so will be greeted by |
468 | handle signal and child watchers, and attempts to do so will be greeted by |
469 | undefined behaviour (or a failed assertion if assertions are enabled). |
469 | undefined behaviour (or a failed assertion if assertions are enabled). |
|
|
470 | |
|
|
471 | Note that this function I<is> thread-safe, and the recommended way to use |
|
|
472 | libev with threads is indeed to create one loop per thread, and using the |
|
|
473 | default loop in the "main" or "initial" thread. |
470 | |
474 | |
471 | Example: Try to create a event loop that uses epoll and nothing else. |
475 | Example: Try to create a event loop that uses epoll and nothing else. |
472 | |
476 | |
473 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
477 | struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV); |
474 | if (!epoller) |
478 | if (!epoller) |
… | |
… | |
1085 | To support fork in your programs, you either have to call |
1089 | To support fork in your programs, you either have to call |
1086 | C<ev_default_fork ()> or C<ev_loop_fork ()> after a fork in the child, |
1090 | C<ev_default_fork ()> or C<ev_loop_fork ()> after a fork in the child, |
1087 | enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or |
1091 | enable C<EVFLAG_FORKCHECK>, or resort to C<EVBACKEND_SELECT> or |
1088 | C<EVBACKEND_POLL>. |
1092 | C<EVBACKEND_POLL>. |
1089 | |
1093 | |
|
|
1094 | =head3 The special problem of SIGPIPE |
|
|
1095 | |
|
|
1096 | While not really specific to libev, it is easy to forget about SIGPIPE: |
|
|
1097 | when reading from a pipe whose other end has been closed, your program |
|
|
1098 | gets send a SIGPIPE, which, by default, aborts your program. For most |
|
|
1099 | programs this is sensible behaviour, for daemons, this is usually |
|
|
1100 | undesirable. |
|
|
1101 | |
|
|
1102 | So when you encounter spurious, unexplained daemon exits, make sure you |
|
|
1103 | ignore SIGPIPE (and maybe make sure you log the exit status of your daemon |
|
|
1104 | somewhere, as that would have given you a big clue). |
|
|
1105 | |
1090 | |
1106 | |
1091 | =head3 Watcher-Specific Functions |
1107 | =head3 Watcher-Specific Functions |
1092 | |
1108 | |
1093 | =over 4 |
1109 | =over 4 |
1094 | |
1110 | |
… | |
… | |
1357 | Simply stops and restarts the periodic watcher again. This is only useful |
1373 | Simply stops and restarts the periodic watcher again. This is only useful |
1358 | when you changed some parameters or the reschedule callback would return |
1374 | when you changed some parameters or the reschedule callback would return |
1359 | a different time than the last time it was called (e.g. in a crond like |
1375 | a different time than the last time it was called (e.g. in a crond like |
1360 | program when the crontabs have changed). |
1376 | program when the crontabs have changed). |
1361 | |
1377 | |
|
|
1378 | =item ev_tstamp ev_periodic_at (ev_periodic *) |
|
|
1379 | |
|
|
1380 | When active, returns the absolute time that the watcher is supposed to |
|
|
1381 | trigger next. |
|
|
1382 | |
1362 | =item ev_tstamp offset [read-write] |
1383 | =item ev_tstamp offset [read-write] |
1363 | |
1384 | |
1364 | When repeating, this contains the offset value, otherwise this is the |
1385 | When repeating, this contains the offset value, otherwise this is the |
1365 | absolute point in time (the C<at> value passed to C<ev_periodic_set>). |
1386 | absolute point in time (the C<at> value passed to C<ev_periodic_set>). |
1366 | |
1387 | |
… | |
… | |
1376 | =item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write] |
1397 | =item ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write] |
1377 | |
1398 | |
1378 | The current reschedule callback, or C<0>, if this functionality is |
1399 | The current reschedule callback, or C<0>, if this functionality is |
1379 | switched off. Can be changed any time, but changes only take effect when |
1400 | switched off. Can be changed any time, but changes only take effect when |
1380 | the periodic timer fires or C<ev_periodic_again> is being called. |
1401 | the periodic timer fires or C<ev_periodic_again> is being called. |
1381 | |
|
|
1382 | =item ev_tstamp at [read-only] |
|
|
1383 | |
|
|
1384 | When active, contains the absolute time that the watcher is supposed to |
|
|
1385 | trigger next. |
|
|
1386 | |
1402 | |
1387 | =back |
1403 | =back |
1388 | |
1404 | |
1389 | =head3 Examples |
1405 | =head3 Examples |
1390 | |
1406 | |
… | |
… | |
1594 | as even with OS-supported change notifications, this can be |
1610 | as even with OS-supported change notifications, this can be |
1595 | resource-intensive. |
1611 | resource-intensive. |
1596 | |
1612 | |
1597 | At the time of this writing, only the Linux inotify interface is |
1613 | At the time of this writing, only the Linux inotify interface is |
1598 | implemented (implementing kqueue support is left as an exercise for the |
1614 | implemented (implementing kqueue support is left as an exercise for the |
|
|
1615 | reader, note, however, that the author sees no way of implementing ev_stat |
1599 | reader). Inotify will be used to give hints only and should not change the |
1616 | semantics with kqueue). Inotify will be used to give hints only and should |
1600 | semantics of C<ev_stat> watchers, which means that libev sometimes needs |
1617 | not change the semantics of C<ev_stat> watchers, which means that libev |
1601 | to fall back to regular polling again even with inotify, but changes are |
1618 | sometimes needs to fall back to regular polling again even with inotify, |
1602 | usually detected immediately, and if the file exists there will be no |
1619 | but changes are usually detected immediately, and if the file exists there |
1603 | polling. |
1620 | will be no polling. |
1604 | |
1621 | |
1605 | =head3 ABI Issues (Largefile Support) |
1622 | =head3 ABI Issues (Largefile Support) |
1606 | |
1623 | |
1607 | Libev by default (unless the user overrides this) uses the default |
1624 | Libev by default (unless the user overrides this) uses the default |
1608 | compilation environment, which means that on systems with optionally |
1625 | compilation environment, which means that on systems with optionally |
… | |
… | |
1618 | When C<inotify (7)> support has been compiled into libev (generally only |
1635 | When C<inotify (7)> support has been compiled into libev (generally only |
1619 | available on Linux) and present at runtime, it will be used to speed up |
1636 | available on Linux) and present at runtime, it will be used to speed up |
1620 | change detection where possible. The inotify descriptor will be created lazily |
1637 | change detection where possible. The inotify descriptor will be created lazily |
1621 | when the first C<ev_stat> watcher is being started. |
1638 | when the first C<ev_stat> watcher is being started. |
1622 | |
1639 | |
1623 | Inotify presense does not change the semantics of C<ev_stat> watchers |
1640 | Inotify presence does not change the semantics of C<ev_stat> watchers |
1624 | except that changes might be detected earlier, and in some cases, to avoid |
1641 | except that changes might be detected earlier, and in some cases, to avoid |
1625 | making regular C<stat> calls. Even in the presense of inotify support |
1642 | making regular C<stat> calls. Even in the presence of inotify support |
1626 | there are many cases where libev has to resort to regular C<stat> polling. |
1643 | there are many cases where libev has to resort to regular C<stat> polling. |
1627 | |
1644 | |
1628 | (There is no support for kqueue, as apparently it cannot be used to |
1645 | (There is no support for kqueue, as apparently it cannot be used to |
1629 | implement this functionality, due to the requirement of having a file |
1646 | implement this functionality, due to the requirement of having a file |
1630 | descriptor open on the object at all times). |
1647 | descriptor open on the object at all times). |
… | |
… | |
1633 | |
1650 | |
1634 | The C<stat ()> syscall only supports full-second resolution portably, and |
1651 | The C<stat ()> syscall only supports full-second resolution portably, and |
1635 | even on systems where the resolution is higher, many filesystems still |
1652 | even on systems where the resolution is higher, many filesystems still |
1636 | only support whole seconds. |
1653 | only support whole seconds. |
1637 | |
1654 | |
1638 | That means that, if the time is the only thing that changes, you might |
1655 | That means that, if the time is the only thing that changes, you can |
1639 | miss updates: on the first update, C<ev_stat> detects a change and calls |
1656 | easily miss updates: on the first update, C<ev_stat> detects a change and |
1640 | your callback, which does something. When there is another update within |
1657 | calls your callback, which does something. When there is another update |
1641 | the same second, C<ev_stat> will be unable to detect it. |
1658 | within the same second, C<ev_stat> will be unable to detect it as the stat |
|
|
1659 | data does not change. |
1642 | |
1660 | |
1643 | The solution to this is to delay acting on a change for a second (or till |
1661 | The solution to this is to delay acting on a change for slightly more |
1644 | the next second boundary), using a roughly one-second delay C<ev_timer> |
1662 | than second (or till slightly after the next full second boundary), using |
1645 | (C<ev_timer_set (w, 0., 1.01); ev_timer_again (loop, w)>). The C<.01> |
1663 | a roughly one-second-delay C<ev_timer> (e.g. C<ev_timer_set (w, 0., 1.02); |
1646 | is added to work around small timing inconsistencies of some operating |
1664 | ev_timer_again (loop, w)>). |
1647 | systems. |
1665 | |
|
|
1666 | The C<.02> offset is added to work around small timing inconsistencies |
|
|
1667 | of some operating systems (where the second counter of the current time |
|
|
1668 | might be be delayed. One such system is the Linux kernel, where a call to |
|
|
1669 | C<gettimeofday> might return a timestamp with a full second later than |
|
|
1670 | a subsequent C<time> call - if the equivalent of C<time ()> is used to |
|
|
1671 | update file times then there will be a small window where the kernel uses |
|
|
1672 | the previous second to update file times but libev might already execute |
|
|
1673 | the timer callback). |
1648 | |
1674 | |
1649 | =head3 Watcher-Specific Functions and Data Members |
1675 | =head3 Watcher-Specific Functions and Data Members |
1650 | |
1676 | |
1651 | =over 4 |
1677 | =over 4 |
1652 | |
1678 | |
… | |
… | |
1658 | C<path>. The C<interval> is a hint on how quickly a change is expected to |
1684 | C<path>. The C<interval> is a hint on how quickly a change is expected to |
1659 | be detected and should normally be specified as C<0> to let libev choose |
1685 | be detected and should normally be specified as C<0> to let libev choose |
1660 | a suitable value. The memory pointed to by C<path> must point to the same |
1686 | a suitable value. The memory pointed to by C<path> must point to the same |
1661 | path for as long as the watcher is active. |
1687 | path for as long as the watcher is active. |
1662 | |
1688 | |
1663 | The callback will be receive C<EV_STAT> when a change was detected, |
1689 | The callback will receive C<EV_STAT> when a change was detected, relative |
1664 | relative to the attributes at the time the watcher was started (or the |
1690 | to the attributes at the time the watcher was started (or the last change |
1665 | last change was detected). |
1691 | was detected). |
1666 | |
1692 | |
1667 | =item ev_stat_stat (loop, ev_stat *) |
1693 | =item ev_stat_stat (loop, ev_stat *) |
1668 | |
1694 | |
1669 | Updates the stat buffer immediately with new values. If you change the |
1695 | Updates the stat buffer immediately with new values. If you change the |
1670 | watched path in your callback, you could call this fucntion to avoid |
1696 | watched path in your callback, you could call this function to avoid |
1671 | detecting this change (while introducing a race condition). Can also be |
1697 | detecting this change (while introducing a race condition if you are not |
1672 | useful simply to find out the new values. |
1698 | the only one changing the path). Can also be useful simply to find out the |
|
|
1699 | new values. |
1673 | |
1700 | |
1674 | =item ev_statdata attr [read-only] |
1701 | =item ev_statdata attr [read-only] |
1675 | |
1702 | |
1676 | The most-recently detected attributes of the file. Although the type is of |
1703 | The most-recently detected attributes of the file. Although the type is |
1677 | C<ev_statdata>, this is usually the (or one of the) C<struct stat> types |
1704 | C<ev_statdata>, this is usually the (or one of the) C<struct stat> types |
1678 | suitable for your system. If the C<st_nlink> member is C<0>, then there |
1705 | suitable for your system, but you can only rely on the POSIX-standardised |
|
|
1706 | members to be present. If the C<st_nlink> member is C<0>, then there was |
1679 | was some error while C<stat>ing the file. |
1707 | some error while C<stat>ing the file. |
1680 | |
1708 | |
1681 | =item ev_statdata prev [read-only] |
1709 | =item ev_statdata prev [read-only] |
1682 | |
1710 | |
1683 | The previous attributes of the file. The callback gets invoked whenever |
1711 | The previous attributes of the file. The callback gets invoked whenever |
1684 | C<prev> != C<attr>. |
1712 | C<prev> != C<attr>, or, more precisely, one or more of these members |
|
|
1713 | differ: C<st_dev>, C<st_ino>, C<st_mode>, C<st_nlink>, C<st_uid>, |
|
|
1714 | C<st_gid>, C<st_rdev>, C<st_size>, C<st_atime>, C<st_mtime>, C<st_ctime>. |
1685 | |
1715 | |
1686 | =item ev_tstamp interval [read-only] |
1716 | =item ev_tstamp interval [read-only] |
1687 | |
1717 | |
1688 | The specified interval. |
1718 | The specified interval. |
1689 | |
1719 | |
… | |
… | |
1743 | } |
1773 | } |
1744 | |
1774 | |
1745 | ... |
1775 | ... |
1746 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
1776 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
1747 | ev_stat_start (loop, &passwd); |
1777 | ev_stat_start (loop, &passwd); |
1748 | ev_timer_init (&timer, timer_cb, 0., 1.01); |
1778 | ev_timer_init (&timer, timer_cb, 0., 1.02); |
1749 | |
1779 | |
1750 | |
1780 | |
1751 | =head2 C<ev_idle> - when you've got nothing better to do... |
1781 | =head2 C<ev_idle> - when you've got nothing better to do... |
1752 | |
1782 | |
1753 | Idle watchers trigger events when no other events of the same or higher |
1783 | Idle watchers trigger events when no other events of the same or higher |
… | |
… | |
1841 | |
1871 | |
1842 | It is recommended to give C<ev_check> watchers highest (C<EV_MAXPRI>) |
1872 | It is recommended to give C<ev_check> watchers highest (C<EV_MAXPRI>) |
1843 | priority, to ensure that they are being run before any other watchers |
1873 | priority, to ensure that they are being run before any other watchers |
1844 | after the poll. Also, C<ev_check> watchers (and C<ev_prepare> watchers, |
1874 | after the poll. Also, C<ev_check> watchers (and C<ev_prepare> watchers, |
1845 | too) should not activate ("feed") events into libev. While libev fully |
1875 | too) should not activate ("feed") events into libev. While libev fully |
1846 | supports this, they will be called before other C<ev_check> watchers |
1876 | supports this, they might get executed before other C<ev_check> watchers |
1847 | did their job. As C<ev_check> watchers are often used to embed other |
1877 | did their job. As C<ev_check> watchers are often used to embed other |
1848 | (non-libev) event loops those other event loops might be in an unusable |
1878 | (non-libev) event loops those other event loops might be in an unusable |
1849 | state until their C<ev_check> watcher ran (always remind yourself to |
1879 | state until their C<ev_check> watcher ran (always remind yourself to |
1850 | coexist peacefully with others). |
1880 | coexist peacefully with others). |
1851 | |
1881 | |
… | |
… | |
1866 | =head3 Examples |
1896 | =head3 Examples |
1867 | |
1897 | |
1868 | There are a number of principal ways to embed other event loops or modules |
1898 | There are a number of principal ways to embed other event loops or modules |
1869 | into libev. Here are some ideas on how to include libadns into libev |
1899 | into libev. Here are some ideas on how to include libadns into libev |
1870 | (there is a Perl module named C<EV::ADNS> that does this, which you could |
1900 | (there is a Perl module named C<EV::ADNS> that does this, which you could |
1871 | use for an actually working example. Another Perl module named C<EV::Glib> |
1901 | use as a working example. Another Perl module named C<EV::Glib> embeds a |
1872 | embeds a Glib main context into libev, and finally, C<Glib::EV> embeds EV |
1902 | Glib main context into libev, and finally, C<Glib::EV> embeds EV into the |
1873 | into the Glib event loop). |
1903 | Glib event loop). |
1874 | |
1904 | |
1875 | Method 1: Add IO watchers and a timeout watcher in a prepare handler, |
1905 | Method 1: Add IO watchers and a timeout watcher in a prepare handler, |
1876 | and in a check watcher, destroy them and call into libadns. What follows |
1906 | and in a check watcher, destroy them and call into libadns. What follows |
1877 | is pseudo-code only of course. This requires you to either use a low |
1907 | is pseudo-code only of course. This requires you to either use a low |
1878 | priority for the check watcher or use C<ev_clear_pending> explicitly, as |
1908 | priority for the check watcher or use C<ev_clear_pending> explicitly, as |
… | |
… | |
2268 | |
2298 | |
2269 | This call incurs the overhead of a syscall only once per loop iteration, |
2299 | This call incurs the overhead of a syscall only once per loop iteration, |
2270 | so while the overhead might be noticable, it doesn't apply to repeated |
2300 | so while the overhead might be noticable, it doesn't apply to repeated |
2271 | calls to C<ev_async_send>. |
2301 | calls to C<ev_async_send>. |
2272 | |
2302 | |
|
|
2303 | =item bool = ev_async_pending (ev_async *) |
|
|
2304 | |
|
|
2305 | Returns a non-zero value when C<ev_async_send> has been called on the |
|
|
2306 | watcher but the event has not yet been processed (or even noted) by the |
|
|
2307 | event loop. |
|
|
2308 | |
|
|
2309 | C<ev_async_send> sets a flag in the watcher and wakes up the loop. When |
|
|
2310 | the loop iterates next and checks for the watcher to have become active, |
|
|
2311 | it will reset the flag again. C<ev_async_pending> can be used to very |
|
|
2312 | quickly check wether invoking the loop might be a good idea. |
|
|
2313 | |
|
|
2314 | Not that this does I<not> check wether the watcher itself is pending, only |
|
|
2315 | wether it has been requested to make this watcher pending. |
|
|
2316 | |
2273 | =back |
2317 | =back |
2274 | |
2318 | |
2275 | |
2319 | |
2276 | =head1 OTHER FUNCTIONS |
2320 | =head1 OTHER FUNCTIONS |
2277 | |
2321 | |
… | |
… | |
2348 | |
2392 | |
2349 | =item * Priorities are not currently supported. Initialising priorities |
2393 | =item * Priorities are not currently supported. Initialising priorities |
2350 | will fail and all watchers will have the same priority, even though there |
2394 | will fail and all watchers will have the same priority, even though there |
2351 | is an ev_pri field. |
2395 | is an ev_pri field. |
2352 | |
2396 | |
|
|
2397 | =item * In libevent, the last base created gets the signals, in libev, the |
|
|
2398 | first base created (== the default loop) gets the signals. |
|
|
2399 | |
2353 | =item * Other members are not supported. |
2400 | =item * Other members are not supported. |
2354 | |
2401 | |
2355 | =item * The libev emulation is I<not> ABI compatible to libevent, you need |
2402 | =item * The libev emulation is I<not> ABI compatible to libevent, you need |
2356 | to use the libev header file and library. |
2403 | to use the libev header file and library. |
2357 | |
2404 | |
… | |
… | |
2599 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2646 | =item C<EV_DEFAULT>, C<EV_DEFAULT_> |
2600 | |
2647 | |
2601 | Similar to the other two macros, this gives you the value of the default |
2648 | Similar to the other two macros, this gives you the value of the default |
2602 | loop, if multiple loops are supported ("ev loop default"). |
2649 | loop, if multiple loops are supported ("ev loop default"). |
2603 | |
2650 | |
|
|
2651 | =item C<EV_DEFAULT_UC>, C<EV_DEFAULT_UC_> |
|
|
2652 | |
|
|
2653 | Usage identical to C<EV_DEFAULT> and C<EV_DEFAULT_>, but requires that the |
|
|
2654 | default loop has been initialised (C<UC> == unchecked). Their behaviour |
|
|
2655 | is undefined when the default loop has not been initialised by a previous |
|
|
2656 | execution of C<EV_DEFAULT>, C<EV_DEFAULT_> or C<ev_default_init (...)>. |
|
|
2657 | |
|
|
2658 | It is often prudent to use C<EV_DEFAULT> when initialising the first |
|
|
2659 | watcher in a function but use C<EV_DEFAULT_UC> afterwards. |
|
|
2660 | |
2604 | =back |
2661 | =back |
2605 | |
2662 | |
2606 | Example: Declare and initialise a check watcher, utilising the above |
2663 | Example: Declare and initialise a check watcher, utilising the above |
2607 | macros so it will work regardless of whether multiple loops are supported |
2664 | macros so it will work regardless of whether multiple loops are supported |
2608 | or not. |
2665 | or not. |
… | |
… | |
2703 | |
2760 | |
2704 | libev.m4 |
2761 | libev.m4 |
2705 | |
2762 | |
2706 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2763 | =head2 PREPROCESSOR SYMBOLS/MACROS |
2707 | |
2764 | |
2708 | Libev can be configured via a variety of preprocessor symbols you have to define |
2765 | Libev can be configured via a variety of preprocessor symbols you have to |
2709 | before including any of its files. The default is not to build for multiplicity |
2766 | define before including any of its files. The default in the absense of |
2710 | and only include the select backend. |
2767 | autoconf is noted for every option. |
2711 | |
2768 | |
2712 | =over 4 |
2769 | =over 4 |
2713 | |
2770 | |
2714 | =item EV_STANDALONE |
2771 | =item EV_STANDALONE |
2715 | |
2772 | |
… | |
… | |
2741 | =item EV_USE_NANOSLEEP |
2798 | =item EV_USE_NANOSLEEP |
2742 | |
2799 | |
2743 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2800 | If defined to be C<1>, libev will assume that C<nanosleep ()> is available |
2744 | and will use it for delays. Otherwise it will use C<select ()>. |
2801 | and will use it for delays. Otherwise it will use C<select ()>. |
2745 | |
2802 | |
|
|
2803 | =item EV_USE_EVENTFD |
|
|
2804 | |
|
|
2805 | If defined to be C<1>, then libev will assume that C<eventfd ()> is |
|
|
2806 | available and will probe for kernel support at runtime. This will improve |
|
|
2807 | C<ev_signal> and C<ev_async> performance and reduce resource consumption. |
|
|
2808 | If undefined, it will be enabled if the headers indicate GNU/Linux + Glibc |
|
|
2809 | 2.7 or newer, otherwise disabled. |
|
|
2810 | |
2746 | =item EV_USE_SELECT |
2811 | =item EV_USE_SELECT |
2747 | |
2812 | |
2748 | If undefined or defined to be C<1>, libev will compile in support for the |
2813 | If undefined or defined to be C<1>, libev will compile in support for the |
2749 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2814 | C<select>(2) backend. No attempt at autodetection will be done: if no |
2750 | other method takes over, select will be it. Otherwise the select backend |
2815 | other method takes over, select will be it. Otherwise the select backend |
… | |
… | |
2786 | |
2851 | |
2787 | =item EV_USE_EPOLL |
2852 | =item EV_USE_EPOLL |
2788 | |
2853 | |
2789 | If defined to be C<1>, libev will compile in support for the Linux |
2854 | If defined to be C<1>, libev will compile in support for the Linux |
2790 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2855 | C<epoll>(7) backend. Its availability will be detected at runtime, |
2791 | otherwise another method will be used as fallback. This is the |
2856 | otherwise another method will be used as fallback. This is the preferred |
2792 | preferred backend for GNU/Linux systems. |
2857 | backend for GNU/Linux systems. If undefined, it will be enabled if the |
|
|
2858 | headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2793 | |
2859 | |
2794 | =item EV_USE_KQUEUE |
2860 | =item EV_USE_KQUEUE |
2795 | |
2861 | |
2796 | If defined to be C<1>, libev will compile in support for the BSD style |
2862 | If defined to be C<1>, libev will compile in support for the BSD style |
2797 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
2863 | C<kqueue>(2) backend. Its actual availability will be detected at runtime, |
… | |
… | |
2816 | |
2882 | |
2817 | =item EV_USE_INOTIFY |
2883 | =item EV_USE_INOTIFY |
2818 | |
2884 | |
2819 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2885 | If defined to be C<1>, libev will compile in support for the Linux inotify |
2820 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2886 | interface to speed up C<ev_stat> watchers. Its actual availability will |
2821 | be detected at runtime. |
2887 | be detected at runtime. If undefined, it will be enabled if the headers |
|
|
2888 | indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled. |
2822 | |
2889 | |
2823 | =item EV_ATOMIC_T |
2890 | =item EV_ATOMIC_T |
2824 | |
2891 | |
2825 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2892 | Libev requires an integer type (suitable for storing C<0> or C<1>) whose |
2826 | access is atomic with respect to other threads or signal contexts. No such |
2893 | access is atomic with respect to other threads or signal contexts. No such |
… | |
… | |
3013 | |
3080 | |
3014 | #include "ev_cpp.h" |
3081 | #include "ev_cpp.h" |
3015 | #include "ev.c" |
3082 | #include "ev.c" |
3016 | |
3083 | |
3017 | |
3084 | |
|
|
3085 | =head1 THREADS AND COROUTINES |
|
|
3086 | |
|
|
3087 | =head2 THREADS |
|
|
3088 | |
|
|
3089 | Libev itself is completely threadsafe, but it uses no locking. This |
|
|
3090 | means that you can use as many loops as you want in parallel, as long as |
|
|
3091 | only one thread ever calls into one libev function with the same loop |
|
|
3092 | parameter. |
|
|
3093 | |
|
|
3094 | Or put differently: calls with different loop parameters can be done in |
|
|
3095 | parallel from multiple threads, calls with the same loop parameter must be |
|
|
3096 | done serially (but can be done from different threads, as long as only one |
|
|
3097 | thread ever is inside a call at any point in time, e.g. by using a mutex |
|
|
3098 | per loop). |
|
|
3099 | |
|
|
3100 | If you want to know which design is best for your problem, then I cannot |
|
|
3101 | help you but by giving some generic advice: |
|
|
3102 | |
|
|
3103 | =over 4 |
|
|
3104 | |
|
|
3105 | =item * most applications have a main thread: use the default libev loop |
|
|
3106 | in that thread, or create a seperate thread running only the default loop. |
|
|
3107 | |
|
|
3108 | This helps integrating other libraries or software modules that use libev |
|
|
3109 | themselves and don't care/know about threading. |
|
|
3110 | |
|
|
3111 | =item * one loop per thread is usually a good model. |
|
|
3112 | |
|
|
3113 | Doing this is almost never wrong, sometimes a better-performance model |
|
|
3114 | exists, but it is always a good start. |
|
|
3115 | |
|
|
3116 | =item * other models exist, such as the leader/follower pattern, where one |
|
|
3117 | loop is handed through multiple threads in a kind of round-robbin fashion. |
|
|
3118 | |
|
|
3119 | Chosing a model is hard - look around, learn, know that usually you cna do |
|
|
3120 | better than you currently do :-) |
|
|
3121 | |
|
|
3122 | =item * often you need to talk to some other thread which blocks in the |
|
|
3123 | event loop - C<ev_async> watchers can be used to wake them up from other |
|
|
3124 | threads safely (or from signal contexts...). |
|
|
3125 | |
|
|
3126 | =back |
|
|
3127 | |
|
|
3128 | =head2 COROUTINES |
|
|
3129 | |
|
|
3130 | Libev is much more accomodating to coroutines ("cooperative threads"): |
|
|
3131 | libev fully supports nesting calls to it's functions from different |
|
|
3132 | coroutines (e.g. you can call C<ev_loop> on the same loop from two |
|
|
3133 | different coroutines and switch freely between both coroutines running the |
|
|
3134 | loop, as long as you don't confuse yourself). The only exception is that |
|
|
3135 | you must not do this from C<ev_periodic> reschedule callbacks. |
|
|
3136 | |
|
|
3137 | Care has been invested into making sure that libev does not keep local |
|
|
3138 | state inside C<ev_loop>, and other calls do not usually allow coroutine |
|
|
3139 | switches. |
|
|
3140 | |
|
|
3141 | |
3018 | =head1 COMPLEXITIES |
3142 | =head1 COMPLEXITIES |
3019 | |
3143 | |
3020 | In this section the complexities of (many of) the algorithms used inside |
3144 | In this section the complexities of (many of) the algorithms used inside |
3021 | libev will be explained. For complexity discussions about backends see the |
3145 | libev will be explained. For complexity discussions about backends see the |
3022 | documentation for C<ev_default_init>. |
3146 | documentation for C<ev_default_init>. |
… | |
… | |
3092 | model. Libev still offers limited functionality on this platform in |
3216 | model. Libev still offers limited functionality on this platform in |
3093 | the form of the C<EVBACKEND_SELECT> backend, and only supports socket |
3217 | the form of the C<EVBACKEND_SELECT> backend, and only supports socket |
3094 | descriptors. This only applies when using Win32 natively, not when using |
3218 | descriptors. This only applies when using Win32 natively, not when using |
3095 | e.g. cygwin. |
3219 | e.g. cygwin. |
3096 | |
3220 | |
|
|
3221 | Lifting these limitations would basically require the full |
|
|
3222 | re-implementation of the I/O system. If you are into these kinds of |
|
|
3223 | things, then note that glib does exactly that for you in a very portable |
|
|
3224 | way (note also that glib is the slowest event library known to man). |
|
|
3225 | |
3097 | There is no supported compilation method available on windows except |
3226 | There is no supported compilation method available on windows except |
3098 | embedding it into other applications. |
3227 | embedding it into other applications. |
3099 | |
3228 | |
3100 | Due to the many, low, and arbitrary limits on the win32 platform and the |
3229 | Due to the many, low, and arbitrary limits on the win32 platform and |
3101 | abysmal performance of winsockets, using a large number of sockets is not |
3230 | the abysmal performance of winsockets, using a large number of sockets |
3102 | recommended (and not reasonable). If your program needs to use more than |
3231 | is not recommended (and not reasonable). If your program needs to use |
3103 | a hundred or so sockets, then likely it needs to use a totally different |
3232 | more than a hundred or so sockets, then likely it needs to use a totally |
3104 | implementation for windows, as libev offers the POSIX model, which cannot |
3233 | different implementation for windows, as libev offers the POSIX readyness |
3105 | be implemented efficiently on windows (microsoft monopoly games). |
3234 | notification model, which cannot be implemented efficiently on windows |
|
|
3235 | (microsoft monopoly games). |
3106 | |
3236 | |
3107 | =over 4 |
3237 | =over 4 |
3108 | |
3238 | |
3109 | =item The winsocket select function |
3239 | =item The winsocket select function |
3110 | |
3240 | |
… | |
… | |
3124 | Note that winsockets handling of fd sets is O(n), so you can easily get a |
3254 | Note that winsockets handling of fd sets is O(n), so you can easily get a |
3125 | complexity in the O(n²) range when using win32. |
3255 | complexity in the O(n²) range when using win32. |
3126 | |
3256 | |
3127 | =item Limited number of file descriptors |
3257 | =item Limited number of file descriptors |
3128 | |
3258 | |
3129 | Windows has numerous arbitrary (and low) limits on things. Early versions |
3259 | Windows has numerous arbitrary (and low) limits on things. |
3130 | of winsocket's select only supported waiting for a max. of C<64> handles |
3260 | |
|
|
3261 | Early versions of winsocket's select only supported waiting for a maximum |
3131 | (probably owning to the fact that all windows kernels can only wait for |
3262 | of C<64> handles (probably owning to the fact that all windows kernels |
3132 | C<64> things at the same time internally; microsoft recommends spawning a |
3263 | can only wait for C<64> things at the same time internally; microsoft |
3133 | chain of threads and wait for 63 handles and the previous thread in each). |
3264 | recommends spawning a chain of threads and wait for 63 handles and the |
|
|
3265 | previous thread in each. Great). |
3134 | |
3266 | |
3135 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
3267 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
3136 | to some high number (e.g. C<2048>) before compiling the winsocket select |
3268 | to some high number (e.g. C<2048>) before compiling the winsocket select |
3137 | call (which might be in libev or elsewhere, for example, perl does its own |
3269 | call (which might be in libev or elsewhere, for example, perl does its own |
3138 | select emulation on windows). |
3270 | select emulation on windows). |
… | |
… | |
3150 | calling select (O(n²)) will likely make this unworkable. |
3282 | calling select (O(n²)) will likely make this unworkable. |
3151 | |
3283 | |
3152 | =back |
3284 | =back |
3153 | |
3285 | |
3154 | |
3286 | |
|
|
3287 | =head1 PORTABILITY REQUIREMENTS |
|
|
3288 | |
|
|
3289 | In addition to a working ISO-C implementation, libev relies on a few |
|
|
3290 | additional extensions: |
|
|
3291 | |
|
|
3292 | =over 4 |
|
|
3293 | |
|
|
3294 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
|
|
3295 | |
|
|
3296 | The type C<sig_atomic_t volatile> (or whatever is defined as |
|
|
3297 | C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different |
|
|
3298 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
|
|
3299 | believed to be sufficiently portable. |
|
|
3300 | |
|
|
3301 | =item C<sigprocmask> must work in a threaded environment |
|
|
3302 | |
|
|
3303 | Libev uses C<sigprocmask> to temporarily block signals. This is not |
|
|
3304 | allowed in a threaded program (C<pthread_sigmask> has to be used). Typical |
|
|
3305 | pthread implementations will either allow C<sigprocmask> in the "main |
|
|
3306 | thread" or will block signals process-wide, both behaviours would |
|
|
3307 | be compatible with libev. Interaction between C<sigprocmask> and |
|
|
3308 | C<pthread_sigmask> could complicate things, however. |
|
|
3309 | |
|
|
3310 | The most portable way to handle signals is to block signals in all threads |
|
|
3311 | except the initial one, and run the default loop in the initial thread as |
|
|
3312 | well. |
|
|
3313 | |
|
|
3314 | =item C<long> must be large enough for common memory allocation sizes |
|
|
3315 | |
|
|
3316 | To improve portability and simplify using libev, libev uses C<long> |
|
|
3317 | internally instead of C<size_t> when allocating its data structures. On |
|
|
3318 | non-POSIX systems (Microsoft...) this might be unexpectedly low, but |
|
|
3319 | is still at least 31 bits everywhere, which is enough for hundreds of |
|
|
3320 | millions of watchers. |
|
|
3321 | |
|
|
3322 | =item C<double> must hold a time value in seconds with enough accuracy |
|
|
3323 | |
|
|
3324 | The type C<double> is used to represent timestamps. It is required to |
|
|
3325 | have at least 51 bits of mantissa (and 9 bits of exponent), which is good |
|
|
3326 | enough for at least into the year 4000. This requirement is fulfilled by |
|
|
3327 | implementations implementing IEEE 754 (basically all existing ones). |
|
|
3328 | |
|
|
3329 | =back |
|
|
3330 | |
|
|
3331 | If you know of other additional requirements drop me a note. |
|
|
3332 | |
|
|
3333 | |
3155 | =head1 AUTHOR |
3334 | =head1 AUTHOR |
3156 | |
3335 | |
3157 | Marc Lehmann <libev@schmorp.de>. |
3336 | Marc Lehmann <libev@schmorp.de>. |
3158 | |
3337 | |