| … | |
… | |
| 145 | C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will |
145 | C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will |
| 146 | override the flags completely if it is found in the environment. This is |
146 | override the flags completely if it is found in the environment. This is |
| 147 | useful to try out specific backends to test their performance, or to work |
147 | useful to try out specific backends to test their performance, or to work |
| 148 | around bugs. |
148 | around bugs. |
| 149 | |
149 | |
| 150 | =item C<EVMETHOD_SELECT> (portable select backend) |
150 | =item C<EVMETHOD_SELECT> (value 1, portable select backend) |
| 151 | |
151 | |
|
|
152 | This is your standard select(2) backend. Not I<completely> standard, as |
|
|
153 | libev tries to roll its own fd_set with no limits on the number of fds, |
|
|
154 | but if that fails, expect a fairly low limit on the number of fds when |
|
|
155 | using this backend. It doesn't scale too well (O(highest_fd)), but its usually |
|
|
156 | the fastest backend for a low number of fds. |
|
|
157 | |
| 152 | =item C<EVMETHOD_POLL> (poll backend, available everywhere except on windows) |
158 | =item C<EVMETHOD_POLL> (value 2, poll backend, available everywhere except on windows) |
| 153 | |
159 | |
|
|
160 | And this is your standard poll(2) backend. It's more complicated than |
|
|
161 | select, but handles sparse fds better and has no artificial limit on the |
|
|
162 | number of fds you can use (except it will slow down considerably with a |
|
|
163 | lot of inactive fds). It scales similarly to select, i.e. O(total_fds). |
|
|
164 | |
| 154 | =item C<EVMETHOD_EPOLL> (linux only) |
165 | =item C<EVMETHOD_EPOLL> (value 4, Linux) |
| 155 | |
166 | |
| 156 | =item C<EVMETHOD_KQUEUE> (some bsds only) |
167 | For few fds, this backend is a bit little slower than poll and select, |
|
|
168 | but it scales phenomenally better. While poll and select usually scale like |
|
|
169 | O(total_fds) where n is the total number of fds (or the highest fd), epoll scales |
|
|
170 | either O(1) or O(active_fds). |
| 157 | |
171 | |
|
|
172 | While stopping and starting an I/O watcher in the same iteration will |
|
|
173 | result in some caching, there is still a syscall per such incident |
|
|
174 | (because the fd could point to a different file description now), so its |
|
|
175 | best to avoid that. Also, dup()ed file descriptors might not work very |
|
|
176 | well if you register events for both fds. |
|
|
177 | |
|
|
178 | =item C<EVMETHOD_KQUEUE> (value 8, most BSD clones) |
|
|
179 | |
|
|
180 | Kqueue deserves special mention, as at the time of this writing, it |
|
|
181 | was broken on all BSDs except NetBSD (usually it doesn't work with |
|
|
182 | anything but sockets and pipes, except on Darwin, where of course its |
|
|
183 | completely useless). For this reason its not being "autodetected" unless |
|
|
184 | you explicitly specify the flags (i.e. you don't use EVFLAG_AUTO). |
|
|
185 | |
|
|
186 | It scales in the same way as the epoll backend, but the interface to the |
|
|
187 | kernel is more efficient (which says nothing about its actual speed, of |
|
|
188 | course). While starting and stopping an I/O watcher does not cause an |
|
|
189 | extra syscall as with epoll, it still adds up to four event changes per |
|
|
190 | incident, so its best to avoid that. |
|
|
191 | |
| 158 | =item C<EVMETHOD_DEVPOLL> (solaris 8 only) |
192 | =item C<EVMETHOD_DEVPOLL> (value 16, Solaris 8) |
| 159 | |
193 | |
|
|
194 | This is not implemented yet (and might never be). |
|
|
195 | |
| 160 | =item C<EVMETHOD_PORT> (solaris 10 only) |
196 | =item C<EVMETHOD_PORT> (value 32, Solaris 10) |
|
|
197 | |
|
|
198 | This uses the Solaris 10 port mechanism. As with everything on Solaris, |
|
|
199 | it's really slow, but it still scales very well (O(active_fds)). |
|
|
200 | |
|
|
201 | =item C<EVMETHOD_ALL> |
|
|
202 | |
|
|
203 | Try all backends (even potentially broken ones that wouldn't be tried |
|
|
204 | with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as |
|
|
205 | C<EVMETHOD_ALL & ~EVMETHOD_KQUEUE>. |
|
|
206 | |
|
|
207 | =back |
| 161 | |
208 | |
| 162 | If one or more of these are ored into the flags value, then only these |
209 | If one or more of these are ored into the flags value, then only these |
| 163 | backends will be tried (in the reverse order as given here). If one are |
210 | backends will be tried (in the reverse order as given here). If none are |
| 164 | specified, any backend will do. |
211 | specified, most compiled-in backend will be tried, usually in reverse |
| 165 | |
212 | order of their flag values :) |
| 166 | =back |
|
|
| 167 | |
213 | |
| 168 | =item struct ev_loop *ev_loop_new (unsigned int flags) |
214 | =item struct ev_loop *ev_loop_new (unsigned int flags) |
| 169 | |
215 | |
| 170 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
216 | Similar to C<ev_default_loop>, but always creates a new event loop that is |
| 171 | always distinct from the default loop. Unlike the default loop, it cannot |
217 | always distinct from the default loop. Unlike the default loop, it cannot |
