diff options
| author | root <root> | 2007-11-22 12:28:27 +0000 |
|---|---|---|
| committer | root <root> | 2007-11-22 12:28:27 +0000 |
| commit | 54a57c74105dc818388cec05e6fc874cdbfebf7f (patch) | |
| tree | e59571c411c5e916efecf4cb6b1ee2a0c91d3d57 | |
| parent | 99c0baac0b99f53c7a0bb4a0c5a8a10e8b97605f (diff) | |
*** empty log message ***
| -rw-r--r-- | ev.3 | 5 | ||||
| -rw-r--r-- | ev.c | 15 | ||||
| -rw-r--r-- | ev.h | 1 | ||||
| -rw-r--r-- | ev.html | 7 | ||||
| -rw-r--r-- | ev.pod | 64 |
5 files changed, 75 insertions, 17 deletions
@@ -316,8 +316,9 @@ it's really slow, but it still scales very well (O(active_fds)). .ie n .IP """EVMETHOD_ALL""" 4 .el .IP "\f(CWEVMETHOD_ALL\fR" 4 .IX Item "EVMETHOD_ALL" -Try all backends (even potentially broken ones). Since this is a mask, you -can do stuff like \f(CW\*(C`EVMETHOD_ALL & ~EVMETHOD_KQUEUE\*(C'\fR. +Try all backends (even potentially broken ones that wouldn't be tried +with \f(CW\*(C`EVFLAG_AUTO\*(C'\fR). Since this is a mask, you can do stuff such as +\&\f(CW\*(C`EVMETHOD_ALL & ~EVMETHOD_KQUEUE\*(C'\fR. .RE .RS 4 .Sp @@ -810,11 +810,20 @@ loop_init (EV_P_ unsigned int flags) now_floor = mn_now; rtmn_diff = ev_rt_now - mn_now; - if (!(flags & EVFLAG_NOENV) && !enable_secure () && getenv ("LIBEV_FLAGS")) + if (!(flags & EVFLAG_NOENV) + && !enable_secure () + && getenv ("LIBEV_FLAGS")) flags = atoi (getenv ("LIBEV_FLAGS")); - if (!(flags & 0x0000ffff)) - flags |= 0x0000ffff; + if (!(flags & EVMETHOD_ALL)) + { + flags |= EVMETHOD_ALL; +#if EV_USE_KQUEUE && !defined (__NetBSD__) + /* kqueue is borked on everything but netbsd apparently */ + /* it usually doesn't work correctly on anything but sockets and pipes */ + flags &= ~EVMETHOD_KQUEUE; +#endif + } method = 0; #if EV_USE_PORT @@ -242,6 +242,7 @@ union ev_any_watcher #define EVMETHOD_KQUEUE 0x00000008 /* bsd */ #define EVMETHOD_DEVPOLL 0x00000010 /* solaris 8 */ /* NYI */ #define EVMETHOD_PORT 0x00000020 /* solaris 10 */ +#define EVMETHOD_ALL 0x0000ffff /* all methods, also future ones, or so */ /* flag bits */ #define EVFLAG_NOENV 0x01000000 /* do NOT consult environment */ @@ -6,7 +6,7 @@ <meta name="description" content="Pod documentation for libev" /> <meta name="inputfile" content="<standard input>" /> <meta name="outputfile" content="<standard output>" /> - <meta name="created" content="Thu Nov 22 13:26:17 2007" /> + <meta name="created" content="Thu Nov 22 13:28:34 2007" /> <meta name="generator" content="Pod::Xhtml 1.57" /> <link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head> <body> @@ -239,8 +239,9 @@ it's really slow, but it still scales very well (O(active_fds)).</p> </dd> <dt><code>EVMETHOD_ALL</code></dt> <dd> - <p>Try all backends (even potentially broken ones). Since this is a mask, you -can do stuff like <code>EVMETHOD_ALL & ~EVMETHOD_KQUEUE</code>.</p> + <p>Try all backends (even potentially broken ones that wouldn't be tried +with <code>EVFLAG_AUTO</code>). Since this is a mask, you can do stuff such as +<code>EVMETHOD_ALL & ~EVMETHOD_KQUEUE</code>.</p> </dd> </dl> </p> @@ -147,24 +147,70 @@ override the flags completely if it is found in the environment. This is useful to try out specific backends to test their performance, or to work around bugs. -=item C<EVMETHOD_SELECT> (portable select backend) +=item C<EVMETHOD_SELECT> (value 1, portable select backend) -=item C<EVMETHOD_POLL> (poll backend, available everywhere except on windows) +This is your standard select(2) backend. Not I<completely> standard, as +libev tries to roll its own fd_set with no limits on the number of fds, +but if that fails, expect a fairly low limit on the number of fds when +using this backend. It doesn't scale too well (O(highest_fd)), but its usually +the fastest backend for a low number of fds. -=item C<EVMETHOD_EPOLL> (linux only) +=item C<EVMETHOD_POLL> (value 2, poll backend, available everywhere except on windows) -=item C<EVMETHOD_KQUEUE> (some bsds only) +And this is your standard poll(2) backend. It's more complicated than +select, but handles sparse fds better and has no artificial limit on the +number of fds you can use (except it will slow down considerably with a +lot of inactive fds). It scales similarly to select, i.e. O(total_fds). -=item C<EVMETHOD_DEVPOLL> (solaris 8 only) +=item C<EVMETHOD_EPOLL> (value 4, Linux) -=item C<EVMETHOD_PORT> (solaris 10 only) +For few fds, this backend is a bit little slower than poll and select, +but it scales phenomenally better. While poll and select usually scale like +O(total_fds) where n is the total number of fds (or the highest fd), epoll scales +either O(1) or O(active_fds). -If one or more of these are ored into the flags value, then only these -backends will be tried (in the reverse order as given here). If one are -specified, any backend will do. +While stopping and starting an I/O watcher in the same iteration will +result in some caching, there is still a syscall per such incident +(because the fd could point to a different file description now), so its +best to avoid that. Also, dup()ed file descriptors might not work very +well if you register events for both fds. + +=item C<EVMETHOD_KQUEUE> (value 8, most BSD clones) + +Kqueue deserves special mention, as at the time of this writing, it +was broken on all BSDs except NetBSD (usually it doesn't work with +anything but sockets and pipes, except on Darwin, where of course its +completely useless). For this reason its not being "autodetected" unless +you explicitly specify the flags (i.e. you don't use EVFLAG_AUTO). + +It scales in the same way as the epoll backend, but the interface to the +kernel is more efficient (which says nothing about its actual speed, of +course). While starting and stopping an I/O watcher does not cause an +extra syscall as with epoll, it still adds up to four event changes per +incident, so its best to avoid that. + +=item C<EVMETHOD_DEVPOLL> (value 16, Solaris 8) + +This is not implemented yet (and might never be). + +=item C<EVMETHOD_PORT> (value 32, Solaris 10) + +This uses the Solaris 10 port mechanism. As with everything on Solaris, +it's really slow, but it still scales very well (O(active_fds)). + +=item C<EVMETHOD_ALL> + +Try all backends (even potentially broken ones that wouldn't be tried +with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as +C<EVMETHOD_ALL & ~EVMETHOD_KQUEUE>. =back +If one or more of these are ored into the flags value, then only these +backends will be tried (in the reverse order as given here). If none are +specified, most compiled-in backend will be tried, usually in reverse +order of their flag values :) + =item struct ev_loop *ev_loop_new (unsigned int flags) Similar to C<ev_default_loop>, but always creates a new event loop that is |