… | |
… | |
127 | .\} |
127 | .\} |
128 | .rm #[ #] #H #V #F C |
128 | .rm #[ #] #H #V #F C |
129 | .\" ======================================================================== |
129 | .\" ======================================================================== |
130 | .\" |
130 | .\" |
131 | .IX Title ""<STANDARD INPUT>" 1" |
131 | .IX Title ""<STANDARD INPUT>" 1" |
132 | .TH "<STANDARD INPUT>" 1 "2007-11-18" "perl v5.8.8" "User Contributed Perl Documentation" |
132 | .TH "<STANDARD INPUT>" 1 "2007-11-22" "perl v5.8.8" "User Contributed Perl Documentation" |
133 | .SH "NAME" |
133 | .SH "NAME" |
134 | libev \- a high performance full\-featured event loop written in C |
134 | libev \- a high performance full\-featured event loop written in C |
135 | .SH "SYNOPSIS" |
135 | .SH "SYNOPSIS" |
136 | .IX Header "SYNOPSIS" |
136 | .IX Header "SYNOPSIS" |
137 | .Vb 1 |
137 | .Vb 1 |
… | |
… | |
260 | or setgid) then libev will \fInot\fR look at the environment variable |
260 | or setgid) then libev will \fInot\fR look at the environment variable |
261 | \&\f(CW\*(C`LIBEV_FLAGS\*(C'\fR. Otherwise (the default), this environment variable will |
261 | \&\f(CW\*(C`LIBEV_FLAGS\*(C'\fR. Otherwise (the default), this environment variable will |
262 | override the flags completely if it is found in the environment. This is |
262 | override the flags completely if it is found in the environment. This is |
263 | useful to try out specific backends to test their performance, or to work |
263 | useful to try out specific backends to test their performance, or to work |
264 | around bugs. |
264 | around bugs. |
265 | .ie n .IP """EVMETHOD_SELECT"" (portable select backend)" 4 |
265 | .ie n .IP """EVMETHOD_SELECT"" (value 1, portable select backend)" 4 |
266 | .el .IP "\f(CWEVMETHOD_SELECT\fR (portable select backend)" 4 |
266 | .el .IP "\f(CWEVMETHOD_SELECT\fR (value 1, portable select backend)" 4 |
267 | .IX Item "EVMETHOD_SELECT (portable select backend)" |
267 | .IX Item "EVMETHOD_SELECT (value 1, portable select backend)" |
268 | .PD 0 |
268 | This is your standard \fIselect\fR\|(2) backend. Not \fIcompletely\fR standard, as |
|
|
269 | libev tries to roll its own fd_set with no limits on the number of fds, |
|
|
270 | but if that fails, expect a fairly low limit on the number of fds when |
|
|
271 | using this backend. It doesn't scale too well (O(highest_fd)), but its usually |
|
|
272 | the fastest backend for a low number of fds. |
269 | .ie n .IP """EVMETHOD_POLL"" (poll backend, available everywhere except on windows)" 4 |
273 | .ie n .IP """EVMETHOD_POLL"" (value 2, poll backend, available everywhere except on windows)" 4 |
270 | .el .IP "\f(CWEVMETHOD_POLL\fR (poll backend, available everywhere except on windows)" 4 |
274 | .el .IP "\f(CWEVMETHOD_POLL\fR (value 2, poll backend, available everywhere except on windows)" 4 |
271 | .IX Item "EVMETHOD_POLL (poll backend, available everywhere except on windows)" |
275 | .IX Item "EVMETHOD_POLL (value 2, poll backend, available everywhere except on windows)" |
|
|
276 | And this is your standard \fIpoll\fR\|(2) backend. It's more complicated than |
|
|
277 | select, but handles sparse fds better and has no artificial limit on the |
|
|
278 | number of fds you can use (except it will slow down considerably with a |
|
|
279 | lot of inactive fds). It scales similarly to select, i.e. O(total_fds). |
272 | .ie n .IP """EVMETHOD_EPOLL"" (linux only)" 4 |
280 | .ie n .IP """EVMETHOD_EPOLL"" (value 4, Linux)" 4 |
273 | .el .IP "\f(CWEVMETHOD_EPOLL\fR (linux only)" 4 |
281 | .el .IP "\f(CWEVMETHOD_EPOLL\fR (value 4, Linux)" 4 |
274 | .IX Item "EVMETHOD_EPOLL (linux only)" |
282 | .IX Item "EVMETHOD_EPOLL (value 4, Linux)" |
275 | .ie n .IP """EVMETHOD_KQUEUE"" (some bsds only)" 4 |
283 | For few fds, this backend is a bit little slower than poll and select, |
276 | .el .IP "\f(CWEVMETHOD_KQUEUE\fR (some bsds only)" 4 |
284 | but it scales phenomenally better. While poll and select usually scale like |
277 | .IX Item "EVMETHOD_KQUEUE (some bsds only)" |
285 | O(total_fds) where n is the total number of fds (or the highest fd), epoll scales |
|
|
286 | either O(1) or O(active_fds). |
|
|
287 | .Sp |
|
|
288 | While stopping and starting an I/O watcher in the same iteration will |
|
|
289 | result in some caching, there is still a syscall per such incident |
|
|
290 | (because the fd could point to a different file description now), so its |
|
|
291 | best to avoid that. Also, \fIdup()\fRed file descriptors might not work very |
|
|
292 | well if you register events for both fds. |
|
|
293 | .ie n .IP """EVMETHOD_KQUEUE"" (value 8, most \s-1BSD\s0 clones)" 4 |
|
|
294 | .el .IP "\f(CWEVMETHOD_KQUEUE\fR (value 8, most \s-1BSD\s0 clones)" 4 |
|
|
295 | .IX Item "EVMETHOD_KQUEUE (value 8, most BSD clones)" |
|
|
296 | Kqueue deserves special mention, as at the time of this writing, it |
|
|
297 | was broken on all BSDs except NetBSD (usually it doesn't work with |
|
|
298 | anything but sockets and pipes, except on Darwin, where of course its |
|
|
299 | completely useless). For this reason its not being \*(L"autodetected\*(R" unless |
|
|
300 | you explicitly specify the flags (i.e. you don't use \s-1EVFLAG_AUTO\s0). |
|
|
301 | .Sp |
|
|
302 | It scales in the same way as the epoll backend, but the interface to the |
|
|
303 | kernel is more efficient (which says nothing about its actual speed, of |
|
|
304 | course). While starting and stopping an I/O watcher does not cause an |
|
|
305 | extra syscall as with epoll, it still adds up to four event changes per |
|
|
306 | incident, so its best to avoid that. |
278 | .ie n .IP """EVMETHOD_DEVPOLL"" (solaris 8 only)" 4 |
307 | .ie n .IP """EVMETHOD_DEVPOLL"" (value 16, Solaris 8)" 4 |
279 | .el .IP "\f(CWEVMETHOD_DEVPOLL\fR (solaris 8 only)" 4 |
308 | .el .IP "\f(CWEVMETHOD_DEVPOLL\fR (value 16, Solaris 8)" 4 |
280 | .IX Item "EVMETHOD_DEVPOLL (solaris 8 only)" |
309 | .IX Item "EVMETHOD_DEVPOLL (value 16, Solaris 8)" |
|
|
310 | This is not implemented yet (and might never be). |
281 | .ie n .IP """EVMETHOD_PORT"" (solaris 10 only)" 4 |
311 | .ie n .IP """EVMETHOD_PORT"" (value 32, Solaris 10)" 4 |
282 | .el .IP "\f(CWEVMETHOD_PORT\fR (solaris 10 only)" 4 |
312 | .el .IP "\f(CWEVMETHOD_PORT\fR (value 32, Solaris 10)" 4 |
283 | .IX Item "EVMETHOD_PORT (solaris 10 only)" |
313 | .IX Item "EVMETHOD_PORT (value 32, Solaris 10)" |
284 | .PD |
314 | This uses the Solaris 10 port mechanism. As with everything on Solaris, |
285 | If one or more of these are ored into the flags value, then only these |
315 | it's really slow, but it still scales very well (O(active_fds)). |
286 | backends will be tried (in the reverse order as given here). If one are |
316 | .ie n .IP """EVMETHOD_ALL""" 4 |
287 | specified, any backend will do. |
317 | .el .IP "\f(CWEVMETHOD_ALL\fR" 4 |
|
|
318 | .IX Item "EVMETHOD_ALL" |
|
|
319 | Try all backends (even potentially broken ones). Since this is a mask, you |
|
|
320 | can do stuff like \f(CW\*(C`EVMETHOD_ALL & ~EVMETHOD_KQUEUE\*(C'\fR. |
288 | .RE |
321 | .RE |
289 | .RS 4 |
322 | .RS 4 |
|
|
323 | .Sp |
|
|
324 | If one or more of these are ored into the flags value, then only these |
|
|
325 | backends will be tried (in the reverse order as given here). If none are |
|
|
326 | specified, most compiled-in backend will be tried, usually in reverse |
|
|
327 | order of their flag values :) |
290 | .RE |
328 | .RE |
291 | .IP "struct ev_loop *ev_loop_new (unsigned int flags)" 4 |
329 | .IP "struct ev_loop *ev_loop_new (unsigned int flags)" 4 |
292 | .IX Item "struct ev_loop *ev_loop_new (unsigned int flags)" |
330 | .IX Item "struct ev_loop *ev_loop_new (unsigned int flags)" |
293 | Similar to \f(CW\*(C`ev_default_loop\*(C'\fR, but always creates a new event loop that is |
331 | Similar to \f(CW\*(C`ev_default_loop\*(C'\fR, but always creates a new event loop that is |
294 | always distinct from the default loop. Unlike the default loop, it cannot |
332 | always distinct from the default loop. Unlike the default loop, it cannot |