… | |
… | |
64 | |
64 | |
65 | =head1 DESCRIPTION |
65 | =head1 DESCRIPTION |
66 | |
66 | |
67 | The newest version of this document is also available as an html-formatted |
67 | The newest version of this document is also available as an html-formatted |
68 | web page you might find easier to navigate when reading it for the first |
68 | web page you might find easier to navigate when reading it for the first |
69 | time: L<http://cvs.schmorp.de/libev/ev.html>. |
69 | time: L<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod>. |
70 | |
70 | |
71 | Libev is an event loop: you register interest in certain events (such as a |
71 | Libev is an event loop: you register interest in certain events (such as a |
72 | file descriptor being readable or a timeout occurring), and it will manage |
72 | file descriptor being readable or a timeout occurring), and it will manage |
73 | these event sources and provide your program with events. |
73 | these event sources and provide your program with events. |
74 | |
74 | |
… | |
… | |
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 (;;) |
… | |
… | |
1370 | 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 |
1371 | when you changed some parameters or the reschedule callback would return |
1374 | when you changed some parameters or the reschedule callback would return |
1372 | 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 |
1373 | program when the crontabs have changed). |
1376 | program when the crontabs have changed). |
1374 | |
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 | |
1375 | =item ev_tstamp offset [read-write] |
1383 | =item ev_tstamp offset [read-write] |
1376 | |
1384 | |
1377 | When repeating, this contains the offset value, otherwise this is the |
1385 | When repeating, this contains the offset value, otherwise this is the |
1378 | 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>). |
1379 | |
1387 | |
… | |
… | |
1389 | =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] |
1390 | |
1398 | |
1391 | The current reschedule callback, or C<0>, if this functionality is |
1399 | The current reschedule callback, or C<0>, if this functionality is |
1392 | 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 |
1393 | 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. |
1394 | |
|
|
1395 | =item ev_tstamp at [read-only] |
|
|
1396 | |
|
|
1397 | When active, contains the absolute time that the watcher is supposed to |
|
|
1398 | trigger next. |
|
|
1399 | |
1402 | |
1400 | =back |
1403 | =back |
1401 | |
1404 | |
1402 | =head3 Examples |
1405 | =head3 Examples |
1403 | |
1406 | |
… | |
… | |
1607 | as even with OS-supported change notifications, this can be |
1610 | as even with OS-supported change notifications, this can be |
1608 | resource-intensive. |
1611 | resource-intensive. |
1609 | |
1612 | |
1610 | 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 |
1611 | 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 |
1612 | 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 |
1613 | 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 |
1614 | 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, |
1615 | 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 |
1616 | polling. |
1620 | will be no polling. |
1617 | |
1621 | |
1618 | =head3 ABI Issues (Largefile Support) |
1622 | =head3 ABI Issues (Largefile Support) |
1619 | |
1623 | |
1620 | Libev by default (unless the user overrides this) uses the default |
1624 | Libev by default (unless the user overrides this) uses the default |
1621 | compilation environment, which means that on systems with optionally |
1625 | compilation environment, which means that on systems with optionally |
… | |
… | |
1631 | 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 |
1632 | 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 |
1633 | change detection where possible. The inotify descriptor will be created lazily |
1637 | change detection where possible. The inotify descriptor will be created lazily |
1634 | when the first C<ev_stat> watcher is being started. |
1638 | when the first C<ev_stat> watcher is being started. |
1635 | |
1639 | |
1636 | 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 |
1637 | 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 |
1638 | 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 |
1639 | 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. |
1640 | |
1644 | |
1641 | (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 |
1642 | implement this functionality, due to the requirement of having a file |
1646 | implement this functionality, due to the requirement of having a file |
1643 | descriptor open on the object at all times). |
1647 | descriptor open on the object at all times). |
… | |
… | |
1646 | |
1650 | |
1647 | The C<stat ()> syscall only supports full-second resolution portably, and |
1651 | The C<stat ()> syscall only supports full-second resolution portably, and |
1648 | even on systems where the resolution is higher, many filesystems still |
1652 | even on systems where the resolution is higher, many filesystems still |
1649 | only support whole seconds. |
1653 | only support whole seconds. |
1650 | |
1654 | |
1651 | 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 |
1652 | 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 |
1653 | your callback, which does something. When there is another update within |
1657 | calls your callback, which does something. When there is another update |
1654 | 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. |
1655 | |
1660 | |
1656 | 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 |
1657 | 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 |
1658 | (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); |
1659 | is added to work around small timing inconsistencies of some operating |
1664 | ev_timer_again (loop, w)>). |
1660 | 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). |
1661 | |
1674 | |
1662 | =head3 Watcher-Specific Functions and Data Members |
1675 | =head3 Watcher-Specific Functions and Data Members |
1663 | |
1676 | |
1664 | =over 4 |
1677 | =over 4 |
1665 | |
1678 | |
… | |
… | |
1671 | 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 |
1672 | 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 |
1673 | 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 |
1674 | path for as long as the watcher is active. |
1687 | path for as long as the watcher is active. |
1675 | |
1688 | |
1676 | 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 |
1677 | 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 |
1678 | last change was detected). |
1691 | was detected). |
1679 | |
1692 | |
1680 | =item ev_stat_stat (loop, ev_stat *) |
1693 | =item ev_stat_stat (loop, ev_stat *) |
1681 | |
1694 | |
1682 | 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 |
1683 | 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 |
1684 | detecting this change (while introducing a race condition). Can also be |
1697 | detecting this change (while introducing a race condition if you are not |
1685 | 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. |
1686 | |
1700 | |
1687 | =item ev_statdata attr [read-only] |
1701 | =item ev_statdata attr [read-only] |
1688 | |
1702 | |
1689 | 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 |
1690 | 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 |
1691 | 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 |
1692 | was some error while C<stat>ing the file. |
1707 | some error while C<stat>ing the file. |
1693 | |
1708 | |
1694 | =item ev_statdata prev [read-only] |
1709 | =item ev_statdata prev [read-only] |
1695 | |
1710 | |
1696 | The previous attributes of the file. The callback gets invoked whenever |
1711 | The previous attributes of the file. The callback gets invoked whenever |
1697 | 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>. |
1698 | |
1715 | |
1699 | =item ev_tstamp interval [read-only] |
1716 | =item ev_tstamp interval [read-only] |
1700 | |
1717 | |
1701 | The specified interval. |
1718 | The specified interval. |
1702 | |
1719 | |
… | |
… | |
1756 | } |
1773 | } |
1757 | |
1774 | |
1758 | ... |
1775 | ... |
1759 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
1776 | ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.); |
1760 | ev_stat_start (loop, &passwd); |
1777 | ev_stat_start (loop, &passwd); |
1761 | ev_timer_init (&timer, timer_cb, 0., 1.01); |
1778 | ev_timer_init (&timer, timer_cb, 0., 1.02); |
1762 | |
1779 | |
1763 | |
1780 | |
1764 | =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... |
1765 | |
1782 | |
1766 | 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 |
… | |
… | |
1854 | |
1871 | |
1855 | 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>) |
1856 | 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 |
1857 | 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, |
1858 | too) should not activate ("feed") events into libev. While libev fully |
1875 | too) should not activate ("feed") events into libev. While libev fully |
1859 | 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 |
1860 | 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 |
1861 | (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 |
1862 | 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 |
1863 | coexist peacefully with others). |
1880 | coexist peacefully with others). |
1864 | |
1881 | |
… | |
… | |
1879 | =head3 Examples |
1896 | =head3 Examples |
1880 | |
1897 | |
1881 | 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 |
1882 | 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 |
1883 | (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 |
1884 | 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 |
1885 | 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 |
1886 | into the Glib event loop). |
1903 | Glib event loop). |
1887 | |
1904 | |
1888 | 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, |
1889 | 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 |
1890 | 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 |
1891 | 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 |
… | |
… | |
2375 | |
2392 | |
2376 | =item * Priorities are not currently supported. Initialising priorities |
2393 | =item * Priorities are not currently supported. Initialising priorities |
2377 | 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 |
2378 | is an ev_pri field. |
2395 | is an ev_pri field. |
2379 | |
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 | |
2380 | =item * Other members are not supported. |
2400 | =item * Other members are not supported. |
2381 | |
2401 | |
2382 | =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 |
2383 | to use the libev header file and library. |
2403 | to use the libev header file and library. |
2384 | |
2404 | |
… | |
… | |
2960 | defined to be C<0>, then they are not. |
2980 | defined to be C<0>, then they are not. |
2961 | |
2981 | |
2962 | =item EV_MINIMAL |
2982 | =item EV_MINIMAL |
2963 | |
2983 | |
2964 | If you need to shave off some kilobytes of code at the expense of some |
2984 | If you need to shave off some kilobytes of code at the expense of some |
2965 | speed, define this symbol to C<1>. Currently only used for gcc to override |
2985 | speed, define this symbol to C<1>. Currently this is used to override some |
2966 | some inlining decisions, saves roughly 30% codesize of amd64. |
2986 | inlining decisions, saves roughly 30% codesize of amd64. It also selects a |
|
|
2987 | much smaller 2-heap for timer management over the default 4-heap. |
2967 | |
2988 | |
2968 | =item EV_PID_HASHSIZE |
2989 | =item EV_PID_HASHSIZE |
2969 | |
2990 | |
2970 | C<ev_child> watchers use a small hash table to distribute workload by |
2991 | C<ev_child> watchers use a small hash table to distribute workload by |
2971 | pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more |
2992 | pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more |
… | |
… | |
2977 | C<ev_stat> watchers use a small hash table to distribute workload by |
2998 | C<ev_stat> watchers use a small hash table to distribute workload by |
2978 | inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>), |
2999 | inotify watch id. The default size is C<16> (or C<1> with C<EV_MINIMAL>), |
2979 | usually more than enough. If you need to manage thousands of C<ev_stat> |
3000 | usually more than enough. If you need to manage thousands of C<ev_stat> |
2980 | watchers you might want to increase this value (I<must> be a power of |
3001 | watchers you might want to increase this value (I<must> be a power of |
2981 | two). |
3002 | two). |
|
|
3003 | |
|
|
3004 | =item EV_USE_4HEAP |
|
|
3005 | |
|
|
3006 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
|
|
3007 | timer and periodics heap, libev uses a 4-heap when this symbol is defined |
|
|
3008 | to C<1>. The 4-heap uses more complicated (longer) code but has a |
|
|
3009 | noticable after performance with many (thousands) of watchers. |
|
|
3010 | |
|
|
3011 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
|
|
3012 | (disabled). |
|
|
3013 | |
|
|
3014 | =item EV_HEAP_CACHE_AT |
|
|
3015 | |
|
|
3016 | Heaps are not very cache-efficient. To improve the cache-efficiency of the |
|
|
3017 | timer and periodics heap, libev can cache the timestamp (I<at>) within |
|
|
3018 | the heap structure (selected by defining C<EV_HEAP_CACHE_AT> to C<1>), |
|
|
3019 | which uses 8-12 bytes more per watcher and a few hundred bytes more code, |
|
|
3020 | but avoids random read accesses on heap changes. This noticably improves |
|
|
3021 | performance noticably with with many (hundreds) of watchers. |
|
|
3022 | |
|
|
3023 | The default is C<1> unless C<EV_MINIMAL> is set in which case it is C<0> |
|
|
3024 | (disabled). |
2982 | |
3025 | |
2983 | =item EV_COMMON |
3026 | =item EV_COMMON |
2984 | |
3027 | |
2985 | By default, all watchers have a C<void *data> member. By redefining |
3028 | By default, all watchers have a C<void *data> member. By redefining |
2986 | this macro to a something else you can include more and other types of |
3029 | this macro to a something else you can include more and other types of |
… | |
… | |
3156 | correct watcher to remove. The lists are usually short (you don't usually |
3199 | correct watcher to remove. The lists are usually short (you don't usually |
3157 | have many watchers waiting for the same fd or signal). |
3200 | have many watchers waiting for the same fd or signal). |
3158 | |
3201 | |
3159 | =item Finding the next timer in each loop iteration: O(1) |
3202 | =item Finding the next timer in each loop iteration: O(1) |
3160 | |
3203 | |
3161 | By virtue of using a binary heap, the next timer is always found at the |
3204 | By virtue of using a binary or 4-heap, the next timer is always found at a |
3162 | beginning of the storage array. |
3205 | fixed position in the storage array. |
3163 | |
3206 | |
3164 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
3207 | =item Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd) |
3165 | |
3208 | |
3166 | A change means an I/O watcher gets started or stopped, which requires |
3209 | A change means an I/O watcher gets started or stopped, which requires |
3167 | libev to recalculate its status (and possibly tell the kernel, depending |
3210 | libev to recalculate its status (and possibly tell the kernel, depending |
… | |
… | |
3196 | model. Libev still offers limited functionality on this platform in |
3239 | model. Libev still offers limited functionality on this platform in |
3197 | the form of the C<EVBACKEND_SELECT> backend, and only supports socket |
3240 | the form of the C<EVBACKEND_SELECT> backend, and only supports socket |
3198 | descriptors. This only applies when using Win32 natively, not when using |
3241 | descriptors. This only applies when using Win32 natively, not when using |
3199 | e.g. cygwin. |
3242 | e.g. cygwin. |
3200 | |
3243 | |
|
|
3244 | Lifting these limitations would basically require the full |
|
|
3245 | re-implementation of the I/O system. If you are into these kinds of |
|
|
3246 | things, then note that glib does exactly that for you in a very portable |
|
|
3247 | way (note also that glib is the slowest event library known to man). |
|
|
3248 | |
3201 | There is no supported compilation method available on windows except |
3249 | There is no supported compilation method available on windows except |
3202 | embedding it into other applications. |
3250 | embedding it into other applications. |
3203 | |
3251 | |
3204 | Due to the many, low, and arbitrary limits on the win32 platform and the |
3252 | Due to the many, low, and arbitrary limits on the win32 platform and |
3205 | abysmal performance of winsockets, using a large number of sockets is not |
3253 | the abysmal performance of winsockets, using a large number of sockets |
3206 | recommended (and not reasonable). If your program needs to use more than |
3254 | is not recommended (and not reasonable). If your program needs to use |
3207 | a hundred or so sockets, then likely it needs to use a totally different |
3255 | more than a hundred or so sockets, then likely it needs to use a totally |
3208 | implementation for windows, as libev offers the POSIX model, which cannot |
3256 | different implementation for windows, as libev offers the POSIX readyness |
3209 | be implemented efficiently on windows (microsoft monopoly games). |
3257 | notification model, which cannot be implemented efficiently on windows |
|
|
3258 | (microsoft monopoly games). |
3210 | |
3259 | |
3211 | =over 4 |
3260 | =over 4 |
3212 | |
3261 | |
3213 | =item The winsocket select function |
3262 | =item The winsocket select function |
3214 | |
3263 | |
… | |
… | |
3228 | Note that winsockets handling of fd sets is O(n), so you can easily get a |
3277 | Note that winsockets handling of fd sets is O(n), so you can easily get a |
3229 | complexity in the O(n²) range when using win32. |
3278 | complexity in the O(n²) range when using win32. |
3230 | |
3279 | |
3231 | =item Limited number of file descriptors |
3280 | =item Limited number of file descriptors |
3232 | |
3281 | |
3233 | Windows has numerous arbitrary (and low) limits on things. Early versions |
3282 | Windows has numerous arbitrary (and low) limits on things. |
3234 | of winsocket's select only supported waiting for a max. of C<64> handles |
3283 | |
|
|
3284 | Early versions of winsocket's select only supported waiting for a maximum |
3235 | (probably owning to the fact that all windows kernels can only wait for |
3285 | of C<64> handles (probably owning to the fact that all windows kernels |
3236 | C<64> things at the same time internally; microsoft recommends spawning a |
3286 | can only wait for C<64> things at the same time internally; microsoft |
3237 | chain of threads and wait for 63 handles and the previous thread in each). |
3287 | recommends spawning a chain of threads and wait for 63 handles and the |
|
|
3288 | previous thread in each. Great). |
3238 | |
3289 | |
3239 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
3290 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
3240 | to some high number (e.g. C<2048>) before compiling the winsocket select |
3291 | to some high number (e.g. C<2048>) before compiling the winsocket select |
3241 | call (which might be in libev or elsewhere, for example, perl does its own |
3292 | call (which might be in libev or elsewhere, for example, perl does its own |
3242 | select emulation on windows). |
3293 | select emulation on windows). |
… | |
… | |
3254 | calling select (O(n²)) will likely make this unworkable. |
3305 | calling select (O(n²)) will likely make this unworkable. |
3255 | |
3306 | |
3256 | =back |
3307 | =back |
3257 | |
3308 | |
3258 | |
3309 | |
|
|
3310 | =head1 PORTABILITY REQUIREMENTS |
|
|
3311 | |
|
|
3312 | In addition to a working ISO-C implementation, libev relies on a few |
|
|
3313 | additional extensions: |
|
|
3314 | |
|
|
3315 | =over 4 |
|
|
3316 | |
|
|
3317 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
|
|
3318 | |
|
|
3319 | The type C<sig_atomic_t volatile> (or whatever is defined as |
|
|
3320 | C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different |
|
|
3321 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
|
|
3322 | believed to be sufficiently portable. |
|
|
3323 | |
|
|
3324 | =item C<sigprocmask> must work in a threaded environment |
|
|
3325 | |
|
|
3326 | Libev uses C<sigprocmask> to temporarily block signals. This is not |
|
|
3327 | allowed in a threaded program (C<pthread_sigmask> has to be used). Typical |
|
|
3328 | pthread implementations will either allow C<sigprocmask> in the "main |
|
|
3329 | thread" or will block signals process-wide, both behaviours would |
|
|
3330 | be compatible with libev. Interaction between C<sigprocmask> and |
|
|
3331 | C<pthread_sigmask> could complicate things, however. |
|
|
3332 | |
|
|
3333 | The most portable way to handle signals is to block signals in all threads |
|
|
3334 | except the initial one, and run the default loop in the initial thread as |
|
|
3335 | well. |
|
|
3336 | |
|
|
3337 | =item C<long> must be large enough for common memory allocation sizes |
|
|
3338 | |
|
|
3339 | To improve portability and simplify using libev, libev uses C<long> |
|
|
3340 | internally instead of C<size_t> when allocating its data structures. On |
|
|
3341 | non-POSIX systems (Microsoft...) this might be unexpectedly low, but |
|
|
3342 | is still at least 31 bits everywhere, which is enough for hundreds of |
|
|
3343 | millions of watchers. |
|
|
3344 | |
|
|
3345 | =item C<double> must hold a time value in seconds with enough accuracy |
|
|
3346 | |
|
|
3347 | The type C<double> is used to represent timestamps. It is required to |
|
|
3348 | have at least 51 bits of mantissa (and 9 bits of exponent), which is good |
|
|
3349 | enough for at least into the year 4000. This requirement is fulfilled by |
|
|
3350 | implementations implementing IEEE 754 (basically all existing ones). |
|
|
3351 | |
|
|
3352 | =back |
|
|
3353 | |
|
|
3354 | If you know of other additional requirements drop me a note. |
|
|
3355 | |
|
|
3356 | |
3259 | =head1 AUTHOR |
3357 | =head1 AUTHOR |
3260 | |
3358 | |
3261 | Marc Lehmann <libev@schmorp.de>. |
3359 | Marc Lehmann <libev@schmorp.de>. |
3262 | |
3360 | |