ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.178 by root, Sat Sep 13 18:25:50 2008 UTC vs.
Revision 1.179 by root, Sat Sep 13 19:14:21 2008 UTC

… …
359writing a server, you should C<accept ()> in a loop to accept as many 359writing a server, you should C<accept ()> in a loop to accept as many
360connections as possible during one iteration. You might also want to have 360connections as possible during one iteration. You might also want to have
361a look at C<ev_set_io_collect_interval ()> to increase the amount of 361a look at C<ev_set_io_collect_interval ()> to increase the amount of
362readiness notifications you get per iteration. 362readiness notifications you get per iteration.
363 363
364This backend maps C<EV_READ> to the C<readfds> set and C<EV_WRITE> to the
365C<writefds> set (and to work around Microsoft Windows bugs, also onto the
366C<exceptfds> set on that platform).
367
364=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows) 368=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
365 369
366And this is your standard poll(2) backend. It's more complicated 370And this is your standard poll(2) backend. It's more complicated
367than select, but handles sparse fds better and has no artificial 371than select, but handles sparse fds better and has no artificial
368limit on the number of fds you can use (except it will slow down 372limit on the number of fds you can use (except it will slow down
369considerably with a lot of inactive fds). It scales similarly to select, 373considerably with a lot of inactive fds). It scales similarly to select,
370i.e. O(total_fds). See the entry for C<EVBACKEND_SELECT>, above, for 374i.e. O(total_fds). See the entry for C<EVBACKEND_SELECT>, above, for
371performance tips. 375performance tips.
376
377This backend maps C<EV_READ> to C<POLLIN | POLLERR | POLLHUP>, and
378C<EV_WRITE> to C<POLLOUT | POLLERR | POLLHUP>.
372 379
373=item C<EVBACKEND_EPOLL> (value 4, Linux) 380=item C<EVBACKEND_EPOLL> (value 4, Linux)
374 381
375For few fds, this backend is a bit little slower than poll and select, 382For few fds, this backend is a bit little slower than poll and select,
376but it scales phenomenally better. While poll and select usually scale 383but it scales phenomenally better. While poll and select usually scale
… …
395keep at least one watcher active per fd at all times. 402keep at least one watcher active per fd at all times.
396 403
397While nominally embeddable in other event loops, this feature is broken in 404While nominally embeddable in other event loops, this feature is broken in
398all kernel versions tested so far. 405all kernel versions tested so far.
399 406
407This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
408C<EVBACKEND_POLL>.
409
400=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones) 410=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
401 411
402Kqueue deserves special mention, as at the time of this writing, it 412Kqueue deserves special mention, as at the time of this writing, it
403was broken on all BSDs except NetBSD (usually it doesn't work reliably 413was broken on all BSDs except NetBSD (usually it doesn't work reliably
404with anything but sockets and pipes, except on Darwin, where of course 414with anything but sockets and pipes, except on Darwin, where of course
… …
425almost everywhere, you should only use it when you have a lot of sockets 435almost everywhere, you should only use it when you have a lot of sockets
426(for which it usually works), by embedding it into another event loop 436(for which it usually works), by embedding it into another event loop
427(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>) and using it only for 437(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>) and using it only for
428sockets. 438sockets.
429 439
440This backend maps C<EV_READ> into an C<EVFILT_READ> kevent with
441C<NOTE_EOF>, and C<EV_WRITE> into an C<EVFILT_WRITE> kevent with
442C<NOTE_EOF>.
443
430=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8) 444=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
431 445
432This is not implemented yet (and might never be, unless you send me an 446This is not implemented yet (and might never be, unless you send me an
433implementation). According to reports, C</dev/poll> only supports sockets 447implementation). According to reports, C</dev/poll> only supports sockets
434and is not embeddable, which would limit the usefulness of this backend 448and is not embeddable, which would limit the usefulness of this backend
… …
449might perform better. 463might perform better.
450 464
451On the positive side, ignoring the spurious readiness notifications, this 465On the positive side, ignoring the spurious readiness notifications, this
452backend actually performed to specification in all tests and is fully 466backend actually performed to specification in all tests and is fully
453embeddable, which is a rare feat among the OS-specific backends. 467embeddable, which is a rare feat among the OS-specific backends.
468
469This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
470C<EVBACKEND_POLL>.
454 471
455=item C<EVBACKEND_ALL> 472=item C<EVBACKEND_ALL>
456 473
457Try all backends (even potentially broken ones that wouldn't be tried 474Try all backends (even potentially broken ones that wouldn't be tried
458with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as 475with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines