… | |
… | |
127 | .\} |
127 | .\} |
128 | .rm #[ #] #H #V #F C |
128 | .rm #[ #] #H #V #F C |
129 | .\" ======================================================================== |
129 | .\" ======================================================================== |
130 | .\" |
130 | .\" |
131 | .IX Title "EV 1" |
131 | .IX Title "EV 1" |
132 | .TH EV 1 "2007-12-21" "perl v5.8.8" "User Contributed Perl Documentation" |
132 | .TH EV 1 "2007-12-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 |
… | |
… | |
255 | .IP "ev_tstamp ev_time ()" 4 |
255 | .IP "ev_tstamp ev_time ()" 4 |
256 | .IX Item "ev_tstamp ev_time ()" |
256 | .IX Item "ev_tstamp ev_time ()" |
257 | Returns the current time as libev would use it. Please note that the |
257 | Returns the current time as libev would use it. Please note that the |
258 | \&\f(CW\*(C`ev_now\*(C'\fR function is usually faster and also often returns the timestamp |
258 | \&\f(CW\*(C`ev_now\*(C'\fR function is usually faster and also often returns the timestamp |
259 | you actually want to know. |
259 | you actually want to know. |
|
|
260 | .IP "ev_sleep (ev_tstamp interval)" 4 |
|
|
261 | .IX Item "ev_sleep (ev_tstamp interval)" |
|
|
262 | Sleep for the given interval: The current thread will be blocked until |
|
|
263 | either it is interrupted or the given time interval has passed. Basically |
|
|
264 | this is a subsecond-resolution \f(CW\*(C`sleep ()\*(C'\fR. |
260 | .IP "int ev_version_major ()" 4 |
265 | .IP "int ev_version_major ()" 4 |
261 | .IX Item "int ev_version_major ()" |
266 | .IX Item "int ev_version_major ()" |
262 | .PD 0 |
267 | .PD 0 |
263 | .IP "int ev_version_minor ()" 4 |
268 | .IP "int ev_version_minor ()" 4 |
264 | .IX Item "int ev_version_minor ()" |
269 | .IX Item "int ev_version_minor ()" |
… | |
… | |
446 | .el .IP "\f(CWEVBACKEND_SELECT\fR (value 1, portable select backend)" 4 |
451 | .el .IP "\f(CWEVBACKEND_SELECT\fR (value 1, portable select backend)" 4 |
447 | .IX Item "EVBACKEND_SELECT (value 1, portable select backend)" |
452 | .IX Item "EVBACKEND_SELECT (value 1, portable select backend)" |
448 | This is your standard \fIselect\fR\|(2) backend. Not \fIcompletely\fR standard, as |
453 | This is your standard \fIselect\fR\|(2) backend. Not \fIcompletely\fR standard, as |
449 | libev tries to roll its own fd_set with no limits on the number of fds, |
454 | libev tries to roll its own fd_set with no limits on the number of fds, |
450 | but if that fails, expect a fairly low limit on the number of fds when |
455 | but if that fails, expect a fairly low limit on the number of fds when |
451 | using this backend. It doesn't scale too well (O(highest_fd)), but its usually |
456 | using this backend. It doesn't scale too well (O(highest_fd)), but its |
452 | the fastest backend for a low number of fds. |
457 | usually the fastest backend for a low number of (low\-numbered :) fds. |
|
|
458 | .Sp |
|
|
459 | To get good performance out of this backend you need a high amount of |
|
|
460 | parallelity (most of the file descriptors should be busy). If you are |
|
|
461 | writing a server, you should \f(CW\*(C`accept ()\*(C'\fR in a loop to accept as many |
|
|
462 | connections as possible during one iteration. You might also want to have |
|
|
463 | a look at \f(CW\*(C`ev_set_io_collect_interval ()\*(C'\fR to increase the amount of |
|
|
464 | readyness notifications you get per iteration. |
453 | .ie n .IP """EVBACKEND_POLL"" (value 2, poll backend, available everywhere except on windows)" 4 |
465 | .ie n .IP """EVBACKEND_POLL"" (value 2, poll backend, available everywhere except on windows)" 4 |
454 | .el .IP "\f(CWEVBACKEND_POLL\fR (value 2, poll backend, available everywhere except on windows)" 4 |
466 | .el .IP "\f(CWEVBACKEND_POLL\fR (value 2, poll backend, available everywhere except on windows)" 4 |
455 | .IX Item "EVBACKEND_POLL (value 2, poll backend, available everywhere except on windows)" |
467 | .IX Item "EVBACKEND_POLL (value 2, poll backend, available everywhere except on windows)" |
456 | And this is your standard \fIpoll\fR\|(2) backend. It's more complicated than |
468 | And this is your standard \fIpoll\fR\|(2) backend. It's more complicated |
457 | select, but handles sparse fds better and has no artificial limit on the |
469 | than select, but handles sparse fds better and has no artificial |
458 | number of fds you can use (except it will slow down considerably with a |
470 | limit on the number of fds you can use (except it will slow down |
459 | lot of inactive fds). It scales similarly to select, i.e. O(total_fds). |
471 | considerably with a lot of inactive fds). It scales similarly to select, |
|
|
472 | i.e. O(total_fds). See the entry for \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR, above, for |
|
|
473 | performance tips. |
460 | .ie n .IP """EVBACKEND_EPOLL"" (value 4, Linux)" 4 |
474 | .ie n .IP """EVBACKEND_EPOLL"" (value 4, Linux)" 4 |
461 | .el .IP "\f(CWEVBACKEND_EPOLL\fR (value 4, Linux)" 4 |
475 | .el .IP "\f(CWEVBACKEND_EPOLL\fR (value 4, Linux)" 4 |
462 | .IX Item "EVBACKEND_EPOLL (value 4, Linux)" |
476 | .IX Item "EVBACKEND_EPOLL (value 4, Linux)" |
463 | For few fds, this backend is a bit little slower than poll and select, |
477 | For few fds, this backend is a bit little slower than poll and select, |
464 | but it scales phenomenally better. While poll and select usually scale |
478 | but it scales phenomenally better. While poll and select usually scale |
465 | like O(total_fds) where n is the total number of fds (or the highest fd), |
479 | like O(total_fds) where n is the total number of fds (or the highest fd), |
466 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
480 | epoll scales either O(1) or O(active_fds). The epoll design has a number |
467 | of shortcomings, such as silently dropping events in some hard-to-detect |
481 | of shortcomings, such as silently dropping events in some hard-to-detect |
468 | cases and rewuiring a syscall per fd change, no fork support and bad |
482 | cases and rewiring a syscall per fd change, no fork support and bad |
469 | support for dup: |
483 | support for dup. |
470 | .Sp |
484 | .Sp |
471 | While stopping, setting and starting an I/O watcher in the same iteration |
485 | While stopping, setting and starting an I/O watcher in the same iteration |
472 | will result in some caching, there is still a syscall per such incident |
486 | will result in some caching, there is still a syscall per such incident |
473 | (because the fd could point to a different file description now), so its |
487 | (because the fd could point to a different file description now), so its |
474 | best to avoid that. Also, \f(CW\*(C`dup ()\*(C'\fR'ed file descriptors might not work |
488 | best to avoid that. Also, \f(CW\*(C`dup ()\*(C'\fR'ed file descriptors might not work |
475 | very well if you register events for both fds. |
489 | very well if you register events for both fds. |
476 | .Sp |
490 | .Sp |
477 | Please note that epoll sometimes generates spurious notifications, so you |
491 | Please note that epoll sometimes generates spurious notifications, so you |
478 | need to use non-blocking I/O or other means to avoid blocking when no data |
492 | need to use non-blocking I/O or other means to avoid blocking when no data |
479 | (or space) is available. |
493 | (or space) is available. |
|
|
494 | .Sp |
|
|
495 | Best performance from this backend is achieved by not unregistering all |
|
|
496 | watchers for a file descriptor until it has been closed, if possible, i.e. |
|
|
497 | keep at least one watcher active per fd at all times. |
|
|
498 | .Sp |
|
|
499 | While nominally embeddeble in other event loops, this feature is broken in |
|
|
500 | all kernel versions tested so far. |
480 | .ie n .IP """EVBACKEND_KQUEUE"" (value 8, most \s-1BSD\s0 clones)" 4 |
501 | .ie n .IP """EVBACKEND_KQUEUE"" (value 8, most \s-1BSD\s0 clones)" 4 |
481 | .el .IP "\f(CWEVBACKEND_KQUEUE\fR (value 8, most \s-1BSD\s0 clones)" 4 |
502 | .el .IP "\f(CWEVBACKEND_KQUEUE\fR (value 8, most \s-1BSD\s0 clones)" 4 |
482 | .IX Item "EVBACKEND_KQUEUE (value 8, most BSD clones)" |
503 | .IX Item "EVBACKEND_KQUEUE (value 8, most BSD clones)" |
483 | Kqueue deserves special mention, as at the time of this writing, it |
504 | Kqueue deserves special mention, as at the time of this writing, it |
484 | was broken on \fIall\fR BSDs (usually it doesn't work with anything but |
505 | was broken on all BSDs except NetBSD (usually it doesn't work reliably |
485 | sockets and pipes, except on Darwin, where of course it's completely |
506 | with anything but sockets and pipes, except on Darwin, where of course |
486 | useless. On NetBSD, it seems to work for all the \s-1FD\s0 types I tested, so it |
|
|
487 | is used by default there). For this reason it's not being \*(L"autodetected\*(R" |
507 | it's completely useless). For this reason it's not being \*(L"autodetected\*(R" |
488 | unless you explicitly specify it explicitly in the flags (i.e. using |
508 | unless you explicitly specify it explicitly in the flags (i.e. using |
489 | \&\f(CW\*(C`EVBACKEND_KQUEUE\*(C'\fR) or libev was compiled on a known-to-be-good (\-enough) |
509 | \&\f(CW\*(C`EVBACKEND_KQUEUE\*(C'\fR) or libev was compiled on a known-to-be-good (\-enough) |
490 | system like NetBSD. |
510 | system like NetBSD. |
491 | .Sp |
511 | .Sp |
|
|
512 | You still can embed kqueue into a normal poll or select backend and use it |
|
|
513 | only for sockets (after having made sure that sockets work with kqueue on |
|
|
514 | the target platform). See \f(CW\*(C`ev_embed\*(C'\fR watchers for more info. |
|
|
515 | .Sp |
492 | It scales in the same way as the epoll backend, but the interface to the |
516 | It scales in the same way as the epoll backend, but the interface to the |
493 | kernel is more efficient (which says nothing about its actual speed, |
517 | kernel is more efficient (which says nothing about its actual speed, of |
494 | of course). While stopping, setting and starting an I/O watcher does |
518 | course). While stopping, setting and starting an I/O watcher does never |
495 | never cause an extra syscall as with epoll, it still adds up to two event |
519 | cause an extra syscall as with \f(CW\*(C`EVBACKEND_EPOLL\*(C'\fR, it still adds up to |
496 | changes per incident, support for \f(CW\*(C`fork ()\*(C'\fR is very bad and it drops fds |
520 | two event changes per incident, support for \f(CW\*(C`fork ()\*(C'\fR is very bad and it |
497 | silently in similarly hard-to-detetc cases. |
521 | drops fds silently in similarly hard-to-detect cases. |
|
|
522 | .Sp |
|
|
523 | This backend usually performs well under most conditions. |
|
|
524 | .Sp |
|
|
525 | While nominally embeddable in other event loops, this doesn't work |
|
|
526 | everywhere, so you might need to test for this. And since it is broken |
|
|
527 | almost everywhere, you should only use it when you have a lot of sockets |
|
|
528 | (for which it usually works), by embedding it into another event loop |
|
|
529 | (e.g. \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR) and using it only for |
|
|
530 | sockets. |
498 | .ie n .IP """EVBACKEND_DEVPOLL"" (value 16, Solaris 8)" 4 |
531 | .ie n .IP """EVBACKEND_DEVPOLL"" (value 16, Solaris 8)" 4 |
499 | .el .IP "\f(CWEVBACKEND_DEVPOLL\fR (value 16, Solaris 8)" 4 |
532 | .el .IP "\f(CWEVBACKEND_DEVPOLL\fR (value 16, Solaris 8)" 4 |
500 | .IX Item "EVBACKEND_DEVPOLL (value 16, Solaris 8)" |
533 | .IX Item "EVBACKEND_DEVPOLL (value 16, Solaris 8)" |
501 | This is not implemented yet (and might never be). |
534 | This is not implemented yet (and might never be, unless you send me an |
|
|
535 | implementation). According to reports, \f(CW\*(C`/dev/poll\*(C'\fR only supports sockets |
|
|
536 | and is not embeddable, which would limit the usefulness of this backend |
|
|
537 | immensely. |
502 | .ie n .IP """EVBACKEND_PORT"" (value 32, Solaris 10)" 4 |
538 | .ie n .IP """EVBACKEND_PORT"" (value 32, Solaris 10)" 4 |
503 | .el .IP "\f(CWEVBACKEND_PORT\fR (value 32, Solaris 10)" 4 |
539 | .el .IP "\f(CWEVBACKEND_PORT\fR (value 32, Solaris 10)" 4 |
504 | .IX Item "EVBACKEND_PORT (value 32, Solaris 10)" |
540 | .IX Item "EVBACKEND_PORT (value 32, Solaris 10)" |
505 | This uses the Solaris 10 event port mechanism. As with everything on Solaris, |
541 | This uses the Solaris 10 event port mechanism. As with everything on Solaris, |
506 | it's really slow, but it still scales very well (O(active_fds)). |
542 | it's really slow, but it still scales very well (O(active_fds)). |
507 | .Sp |
543 | .Sp |
508 | Please note that solaris event ports can deliver a lot of spurious |
544 | Please note that solaris event ports can deliver a lot of spurious |
509 | notifications, so you need to use non-blocking I/O or other means to avoid |
545 | notifications, so you need to use non-blocking I/O or other means to avoid |
510 | blocking when no data (or space) is available. |
546 | blocking when no data (or space) is available. |
|
|
547 | .Sp |
|
|
548 | While this backend scales well, it requires one system call per active |
|
|
549 | file descriptor per loop iteration. For small and medium numbers of file |
|
|
550 | descriptors a \*(L"slow\*(R" \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR backend |
|
|
551 | might perform better. |
511 | .ie n .IP """EVBACKEND_ALL""" 4 |
552 | .ie n .IP """EVBACKEND_ALL""" 4 |
512 | .el .IP "\f(CWEVBACKEND_ALL\fR" 4 |
553 | .el .IP "\f(CWEVBACKEND_ALL\fR" 4 |
513 | .IX Item "EVBACKEND_ALL" |
554 | .IX Item "EVBACKEND_ALL" |
514 | Try all backends (even potentially broken ones that wouldn't be tried |
555 | Try all backends (even potentially broken ones that wouldn't be tried |
515 | with \f(CW\*(C`EVFLAG_AUTO\*(C'\fR). Since this is a mask, you can do stuff such as |
556 | with \f(CW\*(C`EVFLAG_AUTO\*(C'\fR). Since this is a mask, you can do stuff such as |
516 | \&\f(CW\*(C`EVBACKEND_ALL & ~EVBACKEND_KQUEUE\*(C'\fR. |
557 | \&\f(CW\*(C`EVBACKEND_ALL & ~EVBACKEND_KQUEUE\*(C'\fR. |
|
|
558 | .Sp |
|
|
559 | It is definitely not recommended to use this flag. |
517 | .RE |
560 | .RE |
518 | .RS 4 |
561 | .RS 4 |
519 | .Sp |
562 | .Sp |
520 | If one or more of these are ored into the flags value, then only these |
563 | If one or more of these are ored into the flags value, then only these |
521 | backends will be tried (in the reverse order as given here). If none are |
564 | backends will be tried (in the reverse order as given here). If none are |
… | |
… | |
724 | .Sp |
767 | .Sp |
725 | .Vb 2 |
768 | .Vb 2 |
726 | \& ev_ref (loop); |
769 | \& ev_ref (loop); |
727 | \& ev_signal_stop (loop, &exitsig); |
770 | \& ev_signal_stop (loop, &exitsig); |
728 | .Ve |
771 | .Ve |
|
|
772 | .IP "ev_set_io_collect_interval (loop, ev_tstamp interval)" 4 |
|
|
773 | .IX Item "ev_set_io_collect_interval (loop, ev_tstamp interval)" |
|
|
774 | .PD 0 |
|
|
775 | .IP "ev_set_timeout_collect_interval (loop, ev_tstamp interval)" 4 |
|
|
776 | .IX Item "ev_set_timeout_collect_interval (loop, ev_tstamp interval)" |
|
|
777 | .PD |
|
|
778 | These advanced functions influence the time that libev will spend waiting |
|
|
779 | for events. Both are by default \f(CW0\fR, meaning that libev will try to |
|
|
780 | invoke timer/periodic callbacks and I/O callbacks with minimum latency. |
|
|
781 | .Sp |
|
|
782 | Setting these to a higher value (the \f(CW\*(C`interval\*(C'\fR \fImust\fR be >= \f(CW0\fR) |
|
|
783 | allows libev to delay invocation of I/O and timer/periodic callbacks to |
|
|
784 | increase efficiency of loop iterations. |
|
|
785 | .Sp |
|
|
786 | The background is that sometimes your program runs just fast enough to |
|
|
787 | handle one (or very few) event(s) per loop iteration. While this makes |
|
|
788 | the program responsive, it also wastes a lot of \s-1CPU\s0 time to poll for new |
|
|
789 | events, especially with backends like \f(CW\*(C`select ()\*(C'\fR which have a high |
|
|
790 | overhead for the actual polling but can deliver many events at once. |
|
|
791 | .Sp |
|
|
792 | By setting a higher \fIio collect interval\fR you allow libev to spend more |
|
|
793 | time collecting I/O events, so you can handle more events per iteration, |
|
|
794 | at the cost of increasing latency. Timeouts (both \f(CW\*(C`ev_periodic\*(C'\fR and |
|
|
795 | \&\f(CW\*(C`ev_timer\*(C'\fR) will be not affected. Setting this to a non-null value will |
|
|
796 | introduce an additional \f(CW\*(C`ev_sleep ()\*(C'\fR call into most loop iterations. |
|
|
797 | .Sp |
|
|
798 | Likewise, by setting a higher \fItimeout collect interval\fR you allow libev |
|
|
799 | to spend more time collecting timeouts, at the expense of increased |
|
|
800 | latency (the watcher callback will be called later). \f(CW\*(C`ev_io\*(C'\fR watchers |
|
|
801 | will not be affected. Setting this to a non-null value will not introduce |
|
|
802 | any overhead in libev. |
|
|
803 | .Sp |
|
|
804 | Many (busy) programs can usually benefit by setting the io collect |
|
|
805 | interval to a value near \f(CW0.1\fR or so, which is often enough for |
|
|
806 | interactive servers (of course not for games), likewise for timeouts. It |
|
|
807 | usually doesn't make much sense to set it to a lower value than \f(CW0.01\fR, |
|
|
808 | as this approsaches the timing granularity of most systems. |
729 | .SH "ANATOMY OF A WATCHER" |
809 | .SH "ANATOMY OF A WATCHER" |
730 | .IX Header "ANATOMY OF A WATCHER" |
810 | .IX Header "ANATOMY OF A WATCHER" |
731 | A watcher is a structure that you create and register to record your |
811 | A watcher is a structure that you create and register to record your |
732 | interest in some event. For instance, if you want to wait for \s-1STDIN\s0 to |
812 | interest in some event. For instance, if you want to wait for \s-1STDIN\s0 to |
733 | become readable, you would create an \f(CW\*(C`ev_io\*(C'\fR watcher for that: |
813 | become readable, you would create an \f(CW\*(C`ev_io\*(C'\fR watcher for that: |
… | |
… | |
1742 | .PP |
1822 | .PP |
1743 | It is recommended to give \f(CW\*(C`ev_check\*(C'\fR watchers highest (\f(CW\*(C`EV_MAXPRI\*(C'\fR) |
1823 | It is recommended to give \f(CW\*(C`ev_check\*(C'\fR watchers highest (\f(CW\*(C`EV_MAXPRI\*(C'\fR) |
1744 | priority, to ensure that they are being run before any other watchers |
1824 | priority, to ensure that they are being run before any other watchers |
1745 | after the poll. Also, \f(CW\*(C`ev_check\*(C'\fR watchers (and \f(CW\*(C`ev_prepare\*(C'\fR watchers, |
1825 | after the poll. Also, \f(CW\*(C`ev_check\*(C'\fR watchers (and \f(CW\*(C`ev_prepare\*(C'\fR watchers, |
1746 | too) should not activate (\*(L"feed\*(R") events into libev. While libev fully |
1826 | too) should not activate (\*(L"feed\*(R") events into libev. While libev fully |
1747 | supports this, they will be called before other \f(CW\*(C`ev_check\*(C'\fR watchers did |
1827 | supports this, they will be called before other \f(CW\*(C`ev_check\*(C'\fR watchers |
1748 | their job. As \f(CW\*(C`ev_check\*(C'\fR watchers are often used to embed other event |
1828 | did their job. As \f(CW\*(C`ev_check\*(C'\fR watchers are often used to embed other |
1749 | loops those other event loops might be in an unusable state until their |
1829 | (non\-libev) event loops those other event loops might be in an unusable |
1750 | \&\f(CW\*(C`ev_check\*(C'\fR watcher ran (always remind yourself to coexist peacefully with |
1830 | state until their \f(CW\*(C`ev_check\*(C'\fR watcher ran (always remind yourself to |
1751 | others). |
1831 | coexist peacefully with others). |
1752 | .PP |
1832 | .PP |
1753 | \fIWatcher-Specific Functions and Data Members\fR |
1833 | \fIWatcher-Specific Functions and Data Members\fR |
1754 | .IX Subsection "Watcher-Specific Functions and Data Members" |
1834 | .IX Subsection "Watcher-Specific Functions and Data Members" |
1755 | .IP "ev_prepare_init (ev_prepare *, callback)" 4 |
1835 | .IP "ev_prepare_init (ev_prepare *, callback)" 4 |
1756 | .IX Item "ev_prepare_init (ev_prepare *, callback)" |
1836 | .IX Item "ev_prepare_init (ev_prepare *, callback)" |
… | |
… | |
1936 | .el .Sh "\f(CWev_embed\fP \- when one backend isn't enough..." |
2016 | .el .Sh "\f(CWev_embed\fP \- when one backend isn't enough..." |
1937 | .IX Subsection "ev_embed - when one backend isn't enough..." |
2017 | .IX Subsection "ev_embed - when one backend isn't enough..." |
1938 | This is a rather advanced watcher type that lets you embed one event loop |
2018 | This is a rather advanced watcher type that lets you embed one event loop |
1939 | into another (currently only \f(CW\*(C`ev_io\*(C'\fR events are supported in the embedded |
2019 | into another (currently only \f(CW\*(C`ev_io\*(C'\fR events are supported in the embedded |
1940 | loop, other types of watchers might be handled in a delayed or incorrect |
2020 | loop, other types of watchers might be handled in a delayed or incorrect |
1941 | fashion and must not be used). (See portability notes, below). |
2021 | fashion and must not be used). |
1942 | .PP |
2022 | .PP |
1943 | There are primarily two reasons you would want that: work around bugs and |
2023 | There are primarily two reasons you would want that: work around bugs and |
1944 | prioritise I/O. |
2024 | prioritise I/O. |
1945 | .PP |
2025 | .PP |
1946 | As an example for a bug workaround, the kqueue backend might only support |
2026 | As an example for a bug workaround, the kqueue backend might only support |
… | |
… | |
2006 | \& ev_embed_start (loop_hi, &embed); |
2086 | \& ev_embed_start (loop_hi, &embed); |
2007 | \& } |
2087 | \& } |
2008 | \& else |
2088 | \& else |
2009 | \& loop_lo = loop_hi; |
2089 | \& loop_lo = loop_hi; |
2010 | .Ve |
2090 | .Ve |
2011 | .Sh "Portability notes" |
|
|
2012 | .IX Subsection "Portability notes" |
|
|
2013 | Kqueue is nominally embeddable, but this is broken on all BSDs that I |
|
|
2014 | tried, in various ways. Usually the embedded event loop will simply never |
|
|
2015 | receive events, sometimes it will only trigger a few times, sometimes in a |
|
|
2016 | loop. Epoll is also nominally embeddable, but many Linux kernel versions |
|
|
2017 | will always eport the epoll fd as ready, even when no events are pending. |
|
|
2018 | .PP |
|
|
2019 | While libev allows embedding these backends (they are contained in |
|
|
2020 | \&\f(CW\*(C`ev_embeddable_backends ()\*(C'\fR), take extreme care that it will actually |
|
|
2021 | work. |
|
|
2022 | .PP |
|
|
2023 | When in doubt, create a dynamic event loop forced to use sockets (this |
|
|
2024 | usually works) and possibly another thread and a pipe or so to report to |
|
|
2025 | your main event loop. |
|
|
2026 | .PP |
2091 | .PP |
2027 | \fIWatcher-Specific Functions and Data Members\fR |
2092 | \fIWatcher-Specific Functions and Data Members\fR |
2028 | .IX Subsection "Watcher-Specific Functions and Data Members" |
2093 | .IX Subsection "Watcher-Specific Functions and Data Members" |
2029 | .IP "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" 4 |
2094 | .IP "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" 4 |
2030 | .IX Item "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" |
2095 | .IX Item "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" |
… | |
… | |
2501 | realtime clock option at compiletime (and assume its availability at |
2566 | realtime clock option at compiletime (and assume its availability at |
2502 | runtime if successful). Otherwise no use of the realtime clock option will |
2567 | runtime if successful). Otherwise no use of the realtime clock option will |
2503 | be attempted. This effectively replaces \f(CW\*(C`gettimeofday\*(C'\fR by \f(CW\*(C`clock_get |
2568 | be attempted. This effectively replaces \f(CW\*(C`gettimeofday\*(C'\fR by \f(CW\*(C`clock_get |
2504 | (CLOCK_REALTIME, ...)\*(C'\fR and will not normally affect correctness. See the |
2569 | (CLOCK_REALTIME, ...)\*(C'\fR and will not normally affect correctness. See the |
2505 | note about libraries in the description of \f(CW\*(C`EV_USE_MONOTONIC\*(C'\fR, though. |
2570 | note about libraries in the description of \f(CW\*(C`EV_USE_MONOTONIC\*(C'\fR, though. |
|
|
2571 | .IP "\s-1EV_USE_NANOSLEEP\s0" 4 |
|
|
2572 | .IX Item "EV_USE_NANOSLEEP" |
|
|
2573 | If defined to be \f(CW1\fR, libev will assume that \f(CW\*(C`nanosleep ()\*(C'\fR is available |
|
|
2574 | and will use it for delays. Otherwise it will use \f(CW\*(C`select ()\*(C'\fR. |
2506 | .IP "\s-1EV_USE_SELECT\s0" 4 |
2575 | .IP "\s-1EV_USE_SELECT\s0" 4 |
2507 | .IX Item "EV_USE_SELECT" |
2576 | .IX Item "EV_USE_SELECT" |
2508 | If undefined or defined to be \f(CW1\fR, libev will compile in support for the |
2577 | If undefined or defined to be \f(CW1\fR, libev will compile in support for the |
2509 | \&\f(CW\*(C`select\*(C'\fR(2) backend. No attempt at autodetection will be done: if no |
2578 | \&\f(CW\*(C`select\*(C'\fR(2) backend. No attempt at autodetection will be done: if no |
2510 | other method takes over, select will be it. Otherwise the select backend |
2579 | other method takes over, select will be it. Otherwise the select backend |