asyncengine 0.0.1.testing
Sign up to get free protection for your applications and to get access to all the features.
- data/README.markdown +0 -0
- data/asyncengine.gemspec +26 -0
- data/ext/asyncengine_ext/asyncengine_ruby.c +82 -0
- data/ext/asyncengine_ext/extconf.rb +47 -0
- data/ext/asyncengine_ext/libuv/AUTHORS +45 -0
- data/ext/asyncengine_ext/libuv/LICENSE +42 -0
- data/ext/asyncengine_ext/libuv/Makefile +119 -0
- data/ext/asyncengine_ext/libuv/README.md +88 -0
- data/ext/asyncengine_ext/libuv/build/gcc_version.py +20 -0
- data/ext/asyncengine_ext/libuv/common.gypi +176 -0
- data/ext/asyncengine_ext/libuv/config-mingw.mk +61 -0
- data/ext/asyncengine_ext/libuv/config-unix.mk +173 -0
- data/ext/asyncengine_ext/libuv/gyp_uv +60 -0
- data/ext/asyncengine_ext/libuv/include/ares.h +591 -0
- data/ext/asyncengine_ext/libuv/include/ares_version.h +24 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/eio.h +403 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/ev.h +838 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/ngx-queue.h +106 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/tree.h +768 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/uv-unix.h +256 -0
- data/ext/asyncengine_ext/libuv/include/uv-private/uv-win.h +458 -0
- data/ext/asyncengine_ext/libuv/include/uv.h +1556 -0
- data/ext/asyncengine_ext/libuv/src/ares/AUTHORS +37 -0
- data/ext/asyncengine_ext/libuv/src/ares/CHANGES +1218 -0
- data/ext/asyncengine_ext/libuv/src/ares/CMakeLists.txt +22 -0
- data/ext/asyncengine_ext/libuv/src/ares/NEWS +21 -0
- data/ext/asyncengine_ext/libuv/src/ares/README +60 -0
- data/ext/asyncengine_ext/libuv/src/ares/README.cares +13 -0
- data/ext/asyncengine_ext/libuv/src/ares/README.msvc +142 -0
- data/ext/asyncengine_ext/libuv/src/ares/README.node +21 -0
- data/ext/asyncengine_ext/libuv/src/ares/RELEASE-NOTES +26 -0
- data/ext/asyncengine_ext/libuv/src/ares/TODO +23 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares__close_sockets.c +66 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares__get_hostent.c +263 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares__read_line.c +71 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares__timeval.c +111 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_cancel.c +63 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_data.c +190 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_data.h +65 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_destroy.c +105 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_dns.h +90 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_expand_name.c +200 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_expand_string.c +75 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_fds.c +63 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_free_hostent.c +42 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_free_string.c +25 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getenv.c +30 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getenv.h +26 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_gethostbyaddr.c +301 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_gethostbyname.c +523 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getnameinfo.c +427 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getopt.c +122 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getopt.h +53 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_getsock.c +72 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_init.c +1809 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_iphlpapi.h +221 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_ipv6.h +78 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_library_init.c +142 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_library_init.h +42 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_llist.c +86 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_llist.h +42 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_mkquery.c +195 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_nowarn.c +181 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_nowarn.h +55 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_options.c +248 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_a_reply.c +263 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_aaaa_reply.c +259 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_mx_reply.c +170 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_ns_reply.c +182 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_ptr_reply.c +217 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_srv_reply.c +179 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_parse_txt_reply.c +201 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_platform.c +11035 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_platform.h +43 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_private.h +355 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_process.c +1295 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_query.c +183 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_rules.h +144 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_search.c +321 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_send.c +134 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_setup.h +199 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_strcasecmp.c +66 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_strcasecmp.h +30 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_strdup.c +42 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_strdup.h +26 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_strerror.c +56 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_timeout.c +80 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_version.c +11 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_writev.c +79 -0
- data/ext/asyncengine_ext/libuv/src/ares/ares_writev.h +36 -0
- data/ext/asyncengine_ext/libuv/src/ares/bitncmp.c +59 -0
- data/ext/asyncengine_ext/libuv/src/ares/bitncmp.h +26 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_cygwin/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_darwin/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_freebsd/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_linux/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_netbsd/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_openbsd/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_sunos/ares_config.h +512 -0
- data/ext/asyncengine_ext/libuv/src/ares/config_win32/ares_config.h +369 -0
- data/ext/asyncengine_ext/libuv/src/ares/get_ver.awk +35 -0
- data/ext/asyncengine_ext/libuv/src/ares/inet_net_pton.c +451 -0
- data/ext/asyncengine_ext/libuv/src/ares/inet_net_pton.h +31 -0
- data/ext/asyncengine_ext/libuv/src/ares/inet_ntop.c +208 -0
- data/ext/asyncengine_ext/libuv/src/ares/inet_ntop.h +26 -0
- data/ext/asyncengine_ext/libuv/src/ares/nameser.h +203 -0
- data/ext/asyncengine_ext/libuv/src/ares/setup_once.h +504 -0
- data/ext/asyncengine_ext/libuv/src/ares/windows_port.c +22 -0
- data/ext/asyncengine_ext/libuv/src/unix/async.c +58 -0
- data/ext/asyncengine_ext/libuv/src/unix/cares.c +194 -0
- data/ext/asyncengine_ext/libuv/src/unix/check.c +80 -0
- data/ext/asyncengine_ext/libuv/src/unix/core.c +588 -0
- data/ext/asyncengine_ext/libuv/src/unix/cygwin.c +84 -0
- data/ext/asyncengine_ext/libuv/src/unix/darwin.c +341 -0
- data/ext/asyncengine_ext/libuv/src/unix/dl.c +91 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/Changes +63 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/LICENSE +36 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/Makefile.am +15 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/aclocal.m4 +8957 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/autogen.sh +3 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config.h.in +86 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_cygwin.h +80 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_darwin.h +141 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_freebsd.h +81 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_linux.h +94 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_netbsd.h +81 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_openbsd.h +137 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/config_sunos.h +84 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/configure.ac +22 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/demo.c +194 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/ecb.h +370 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/eio.3 +3428 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/eio.c +2593 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/eio.pod +969 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/libeio.m4 +195 -0
- data/ext/asyncengine_ext/libuv/src/unix/eio/xthread.h +164 -0
- data/ext/asyncengine_ext/libuv/src/unix/error.c +98 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/Changes +388 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/LICENSE +36 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/Makefile.am +18 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/Makefile.in +771 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/README +58 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/aclocal.m4 +8957 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/autogen.sh +6 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config.guess +1526 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config.h.in +125 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config.sub +1658 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_cygwin.h +123 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_darwin.h +122 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_freebsd.h +120 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_linux.h +141 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_netbsd.h +120 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_openbsd.h +126 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/config_sunos.h +122 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/configure +13037 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/configure.ac +18 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/depcomp +630 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev++.h +816 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev.3 +5311 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev.c +3921 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev.pod +5243 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_epoll.c +266 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_kqueue.c +235 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_poll.c +148 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_port.c +179 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_select.c +310 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_vars.h +203 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_win32.c +153 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ev_wrap.h +196 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/event.c +402 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/event.h +170 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/install-sh +294 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/libev.m4 +39 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/ltmain.sh +8413 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/missing +336 -0
- data/ext/asyncengine_ext/libuv/src/unix/ev/mkinstalldirs +111 -0
- data/ext/asyncengine_ext/libuv/src/unix/freebsd.c +312 -0
- data/ext/asyncengine_ext/libuv/src/unix/fs.c +707 -0
- data/ext/asyncengine_ext/libuv/src/unix/idle.c +79 -0
- data/ext/asyncengine_ext/libuv/src/unix/internal.h +161 -0
- data/ext/asyncengine_ext/libuv/src/unix/kqueue.c +127 -0
- data/ext/asyncengine_ext/libuv/src/unix/linux/core.c +474 -0
- data/ext/asyncengine_ext/libuv/src/unix/linux/inotify.c +211 -0
- data/ext/asyncengine_ext/libuv/src/unix/linux/syscalls.c +230 -0
- data/ext/asyncengine_ext/libuv/src/unix/linux/syscalls.h +87 -0
- data/ext/asyncengine_ext/libuv/src/unix/loop.c +58 -0
- data/ext/asyncengine_ext/libuv/src/unix/netbsd.c +108 -0
- data/ext/asyncengine_ext/libuv/src/unix/openbsd.c +295 -0
- data/ext/asyncengine_ext/libuv/src/unix/pipe.c +266 -0
- data/ext/asyncengine_ext/libuv/src/unix/prepare.c +79 -0
- data/ext/asyncengine_ext/libuv/src/unix/process.c +369 -0
- data/ext/asyncengine_ext/libuv/src/unix/stream.c +1033 -0
- data/ext/asyncengine_ext/libuv/src/unix/sunos.c +466 -0
- data/ext/asyncengine_ext/libuv/src/unix/tcp.c +327 -0
- data/ext/asyncengine_ext/libuv/src/unix/thread.c +154 -0
- data/ext/asyncengine_ext/libuv/src/unix/timer.c +127 -0
- data/ext/asyncengine_ext/libuv/src/unix/tty.c +146 -0
- data/ext/asyncengine_ext/libuv/src/unix/udp.c +670 -0
- data/ext/asyncengine_ext/libuv/src/unix/uv-eio.c +124 -0
- data/ext/asyncengine_ext/libuv/src/unix/uv-eio.h +13 -0
- data/ext/asyncengine_ext/libuv/src/uv-common.c +354 -0
- data/ext/asyncengine_ext/libuv/src/uv-common.h +87 -0
- data/ext/asyncengine_ext/libuv/src/win/async.c +127 -0
- data/ext/asyncengine_ext/libuv/src/win/cares.c +290 -0
- data/ext/asyncengine_ext/libuv/src/win/core.c +270 -0
- data/ext/asyncengine_ext/libuv/src/win/dl.c +82 -0
- data/ext/asyncengine_ext/libuv/src/win/error.c +132 -0
- data/ext/asyncengine_ext/libuv/src/win/fs-event.c +514 -0
- data/ext/asyncengine_ext/libuv/src/win/fs.c +1576 -0
- data/ext/asyncengine_ext/libuv/src/win/getaddrinfo.c +372 -0
- data/ext/asyncengine_ext/libuv/src/win/handle.c +225 -0
- data/ext/asyncengine_ext/libuv/src/win/internal.h +352 -0
- data/ext/asyncengine_ext/libuv/src/win/loop-watcher.c +131 -0
- data/ext/asyncengine_ext/libuv/src/win/pipe.c +1661 -0
- data/ext/asyncengine_ext/libuv/src/win/process.c +1140 -0
- data/ext/asyncengine_ext/libuv/src/win/req.c +174 -0
- data/ext/asyncengine_ext/libuv/src/win/stream.c +201 -0
- data/ext/asyncengine_ext/libuv/src/win/tcp.c +1282 -0
- data/ext/asyncengine_ext/libuv/src/win/thread.c +332 -0
- data/ext/asyncengine_ext/libuv/src/win/threadpool.c +73 -0
- data/ext/asyncengine_ext/libuv/src/win/timer.c +276 -0
- data/ext/asyncengine_ext/libuv/src/win/tty.c +1795 -0
- data/ext/asyncengine_ext/libuv/src/win/udp.c +709 -0
- data/ext/asyncengine_ext/libuv/src/win/util.c +719 -0
- data/ext/asyncengine_ext/libuv/src/win/winapi.c +117 -0
- data/ext/asyncengine_ext/libuv/src/win/winapi.h +4419 -0
- data/ext/asyncengine_ext/libuv/src/win/winsock.c +470 -0
- data/ext/asyncengine_ext/libuv/src/win/winsock.h +138 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-ares.c +118 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-getaddrinfo.c +94 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-list.h +105 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-ping-pongs.c +213 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-pound.c +324 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-pump.c +462 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-sizes.c +40 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-spawn.c +156 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-tcp-write-batch.c +140 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-thread.c +64 -0
- data/ext/asyncengine_ext/libuv/test/benchmark-udp-packet-storm.c +247 -0
- data/ext/asyncengine_ext/libuv/test/blackhole-server.c +118 -0
- data/ext/asyncengine_ext/libuv/test/dns-server.c +321 -0
- data/ext/asyncengine_ext/libuv/test/echo-server.c +370 -0
- data/ext/asyncengine_ext/libuv/test/fixtures/empty_file +0 -0
- data/ext/asyncengine_ext/libuv/test/fixtures/load_error.node +1 -0
- data/ext/asyncengine_ext/libuv/test/run-benchmarks.c +64 -0
- data/ext/asyncengine_ext/libuv/test/run-tests.c +108 -0
- data/ext/asyncengine_ext/libuv/test/runner-unix.c +315 -0
- data/ext/asyncengine_ext/libuv/test/runner-unix.h +36 -0
- data/ext/asyncengine_ext/libuv/test/runner-win.c +343 -0
- data/ext/asyncengine_ext/libuv/test/runner-win.h +42 -0
- data/ext/asyncengine_ext/libuv/test/runner.c +317 -0
- data/ext/asyncengine_ext/libuv/test/runner.h +159 -0
- data/ext/asyncengine_ext/libuv/test/task.h +117 -0
- data/ext/asyncengine_ext/libuv/test/test-async.c +216 -0
- data/ext/asyncengine_ext/libuv/test/test-callback-stack.c +203 -0
- data/ext/asyncengine_ext/libuv/test/test-connection-fail.c +148 -0
- data/ext/asyncengine_ext/libuv/test/test-counters-init.c +216 -0
- data/ext/asyncengine_ext/libuv/test/test-cwd-and-chdir.c +64 -0
- data/ext/asyncengine_ext/libuv/test/test-delayed-accept.c +197 -0
- data/ext/asyncengine_ext/libuv/test/test-dlerror.c +49 -0
- data/ext/asyncengine_ext/libuv/test/test-eio-overflow.c +90 -0
- data/ext/asyncengine_ext/libuv/test/test-error.c +59 -0
- data/ext/asyncengine_ext/libuv/test/test-fail-always.c +29 -0
- data/ext/asyncengine_ext/libuv/test/test-fs-event.c +442 -0
- data/ext/asyncengine_ext/libuv/test/test-fs.c +1731 -0
- data/ext/asyncengine_ext/libuv/test/test-get-currentexe.c +63 -0
- data/ext/asyncengine_ext/libuv/test/test-get-loadavg.c +36 -0
- data/ext/asyncengine_ext/libuv/test/test-get-memory.c +38 -0
- data/ext/asyncengine_ext/libuv/test/test-getaddrinfo.c +122 -0
- data/ext/asyncengine_ext/libuv/test/test-gethostbyname.c +189 -0
- data/ext/asyncengine_ext/libuv/test/test-getsockname.c +342 -0
- data/ext/asyncengine_ext/libuv/test/test-hrtime.c +51 -0
- data/ext/asyncengine_ext/libuv/test/test-idle.c +81 -0
- data/ext/asyncengine_ext/libuv/test/test-ipc-send-recv.c +209 -0
- data/ext/asyncengine_ext/libuv/test/test-ipc.c +614 -0
- data/ext/asyncengine_ext/libuv/test/test-list.h +371 -0
- data/ext/asyncengine_ext/libuv/test/test-loop-handles.c +359 -0
- data/ext/asyncengine_ext/libuv/test/test-multiple-listen.c +102 -0
- data/ext/asyncengine_ext/libuv/test/test-mutexes.c +63 -0
- data/ext/asyncengine_ext/libuv/test/test-pass-always.c +28 -0
- data/ext/asyncengine_ext/libuv/test/test-ping-pong.c +253 -0
- data/ext/asyncengine_ext/libuv/test/test-pipe-bind-error.c +140 -0
- data/ext/asyncengine_ext/libuv/test/test-pipe-connect-error.c +96 -0
- data/ext/asyncengine_ext/libuv/test/test-platform-output.c +87 -0
- data/ext/asyncengine_ext/libuv/test/test-process-title.c +42 -0
- data/ext/asyncengine_ext/libuv/test/test-ref.c +322 -0
- data/ext/asyncengine_ext/libuv/test/test-run-once.c +44 -0
- data/ext/asyncengine_ext/libuv/test/test-shutdown-close.c +103 -0
- data/ext/asyncengine_ext/libuv/test/test-shutdown-eof.c +183 -0
- data/ext/asyncengine_ext/libuv/test/test-spawn.c +499 -0
- data/ext/asyncengine_ext/libuv/test/test-stdio-over-pipes.c +256 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-bind-error.c +191 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-bind6-error.c +154 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-close.c +129 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-connect-error.c +70 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-connect6-error.c +68 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-flags.c +51 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-write-error.c +168 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-write-to-half-open-connection.c +135 -0
- data/ext/asyncengine_ext/libuv/test/test-tcp-writealot.c +195 -0
- data/ext/asyncengine_ext/libuv/test/test-thread.c +183 -0
- data/ext/asyncengine_ext/libuv/test/test-threadpool.c +57 -0
- data/ext/asyncengine_ext/libuv/test/test-timer-again.c +141 -0
- data/ext/asyncengine_ext/libuv/test/test-timer.c +130 -0
- data/ext/asyncengine_ext/libuv/test/test-tty.c +110 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-dgram-too-big.c +86 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-ipv6.c +156 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-multicast-join.c +139 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-multicast-ttl.c +86 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-options.c +86 -0
- data/ext/asyncengine_ext/libuv/test/test-udp-send-and-recv.c +208 -0
- data/ext/asyncengine_ext/libuv/test/test-util.c +97 -0
- data/ext/asyncengine_ext/libuv/uv.gyp +435 -0
- data/ext/asyncengine_ext/libuv/vcbuild.bat +105 -0
- data/lib/asyncengine/version.rb +3 -0
- data/lib/asyncengine.rb +41 -0
- metadata +384 -0
@@ -0,0 +1,3428 @@
|
|
1
|
+
.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05)
|
2
|
+
.\"
|
3
|
+
.\" Standard preamble:
|
4
|
+
.\" ========================================================================
|
5
|
+
.de Sh \" Subsection heading
|
6
|
+
.br
|
7
|
+
.if t .Sp
|
8
|
+
.ne 5
|
9
|
+
.PP
|
10
|
+
\fB\\$1\fR
|
11
|
+
.PP
|
12
|
+
..
|
13
|
+
.de Sp \" Vertical space (when we can't use .PP)
|
14
|
+
.if t .sp .5v
|
15
|
+
.if n .sp
|
16
|
+
..
|
17
|
+
.de Vb \" Begin verbatim text
|
18
|
+
.ft CW
|
19
|
+
.nf
|
20
|
+
.ne \\$1
|
21
|
+
..
|
22
|
+
.de Ve \" End verbatim text
|
23
|
+
.ft R
|
24
|
+
.fi
|
25
|
+
..
|
26
|
+
.\" Set up some character translations and predefined strings. \*(-- will
|
27
|
+
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
|
28
|
+
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
|
29
|
+
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
|
30
|
+
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
|
31
|
+
.\" nothing in troff, for use with C<>.
|
32
|
+
.tr \(*W-
|
33
|
+
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
|
34
|
+
.ie n \{\
|
35
|
+
. ds -- \(*W-
|
36
|
+
. ds PI pi
|
37
|
+
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
|
38
|
+
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
|
39
|
+
. ds L" ""
|
40
|
+
. ds R" ""
|
41
|
+
. ds C` ""
|
42
|
+
. ds C' ""
|
43
|
+
'br\}
|
44
|
+
.el\{\
|
45
|
+
. ds -- \|\(em\|
|
46
|
+
. ds PI \(*p
|
47
|
+
. ds L" ``
|
48
|
+
. ds R" ''
|
49
|
+
'br\}
|
50
|
+
.\"
|
51
|
+
.\" Escape single quotes in literal strings from groff's Unicode transform.
|
52
|
+
.ie \n(.g .ds Aq \(aq
|
53
|
+
.el .ds Aq '
|
54
|
+
.\"
|
55
|
+
.\" If the F register is turned on, we'll generate index entries on stderr for
|
56
|
+
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
|
57
|
+
.\" entries marked with X<> in POD. Of course, you'll have to process the
|
58
|
+
.\" output yourself in some meaningful fashion.
|
59
|
+
.ie \nF \{\
|
60
|
+
. de IX
|
61
|
+
. tm Index:\\$1\t\\n%\t"\\$2"
|
62
|
+
..
|
63
|
+
. nr % 0
|
64
|
+
. rr F
|
65
|
+
.\}
|
66
|
+
.el \{\
|
67
|
+
. de IX
|
68
|
+
..
|
69
|
+
.\}
|
70
|
+
.\"
|
71
|
+
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
|
72
|
+
.\" Fear. Run. Save yourself. No user-serviceable parts.
|
73
|
+
. \" fudge factors for nroff and troff
|
74
|
+
.if n \{\
|
75
|
+
. ds #H 0
|
76
|
+
. ds #V .8m
|
77
|
+
. ds #F .3m
|
78
|
+
. ds #[ \f1
|
79
|
+
. ds #] \fP
|
80
|
+
.\}
|
81
|
+
.if t \{\
|
82
|
+
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
|
83
|
+
. ds #V .6m
|
84
|
+
. ds #F 0
|
85
|
+
. ds #[ \&
|
86
|
+
. ds #] \&
|
87
|
+
.\}
|
88
|
+
. \" simple accents for nroff and troff
|
89
|
+
.if n \{\
|
90
|
+
. ds ' \&
|
91
|
+
. ds ` \&
|
92
|
+
. ds ^ \&
|
93
|
+
. ds , \&
|
94
|
+
. ds ~ ~
|
95
|
+
. ds /
|
96
|
+
.\}
|
97
|
+
.if t \{\
|
98
|
+
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
|
99
|
+
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
|
100
|
+
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
|
101
|
+
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
|
102
|
+
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
|
103
|
+
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
|
104
|
+
.\}
|
105
|
+
. \" troff and (daisy-wheel) nroff accents
|
106
|
+
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
|
107
|
+
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
|
108
|
+
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
|
109
|
+
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
|
110
|
+
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
|
111
|
+
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
|
112
|
+
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
|
113
|
+
.ds ae a\h'-(\w'a'u*4/10)'e
|
114
|
+
.ds Ae A\h'-(\w'A'u*4/10)'E
|
115
|
+
. \" corrections for vroff
|
116
|
+
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
|
117
|
+
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
|
118
|
+
. \" for low resolution devices (crt and lpr)
|
119
|
+
.if \n(.H>23 .if \n(.V>19 \
|
120
|
+
\{\
|
121
|
+
. ds : e
|
122
|
+
. ds 8 ss
|
123
|
+
. ds o a
|
124
|
+
. ds d- d\h'-1'\(ga
|
125
|
+
. ds D- D\h'-1'\(hy
|
126
|
+
. ds th \o'bp'
|
127
|
+
. ds Th \o'LP'
|
128
|
+
. ds ae ae
|
129
|
+
. ds Ae AE
|
130
|
+
.\}
|
131
|
+
.rm #[ #] #H #V #F C
|
132
|
+
.\" ========================================================================
|
133
|
+
.\"
|
134
|
+
.IX Title "LIBEIO 3"
|
135
|
+
.TH LIBEIO 3 "2008-05-11" "libeio-1.0" "libeio - truly asynchronous POSIX I/O"
|
136
|
+
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
|
137
|
+
.\" way too many mistakes in technical documents.
|
138
|
+
.if n .ad l
|
139
|
+
.nh
|
140
|
+
.SH "NAME"
|
141
|
+
libev \- a high performance full\-featured event loop written in C
|
142
|
+
.SH "SYNOPSIS"
|
143
|
+
.IX Header "SYNOPSIS"
|
144
|
+
.Vb 1
|
145
|
+
\& #include <ev.h>
|
146
|
+
.Ve
|
147
|
+
.Sh "\s-1EXAMPLE\s0 \s-1PROGRAM\s0"
|
148
|
+
.IX Subsection "EXAMPLE PROGRAM"
|
149
|
+
.Vb 2
|
150
|
+
\& // a single header file is required
|
151
|
+
\& #include <ev.h>
|
152
|
+
\&
|
153
|
+
\& // every watcher type has its own typedef\*(Aqd struct
|
154
|
+
\& // with the name ev_<type>
|
155
|
+
\& ev_io stdin_watcher;
|
156
|
+
\& ev_timer timeout_watcher;
|
157
|
+
\&
|
158
|
+
\& // all watcher callbacks have a similar signature
|
159
|
+
\& // this callback is called when data is readable on stdin
|
160
|
+
\& static void
|
161
|
+
\& stdin_cb (EV_P_ struct ev_io *w, int revents)
|
162
|
+
\& {
|
163
|
+
\& puts ("stdin ready");
|
164
|
+
\& // for one\-shot events, one must manually stop the watcher
|
165
|
+
\& // with its corresponding stop function.
|
166
|
+
\& ev_io_stop (EV_A_ w);
|
167
|
+
\&
|
168
|
+
\& // this causes all nested ev_loop\*(Aqs to stop iterating
|
169
|
+
\& ev_unloop (EV_A_ EVUNLOOP_ALL);
|
170
|
+
\& }
|
171
|
+
\&
|
172
|
+
\& // another callback, this time for a time\-out
|
173
|
+
\& static void
|
174
|
+
\& timeout_cb (EV_P_ struct ev_timer *w, int revents)
|
175
|
+
\& {
|
176
|
+
\& puts ("timeout");
|
177
|
+
\& // this causes the innermost ev_loop to stop iterating
|
178
|
+
\& ev_unloop (EV_A_ EVUNLOOP_ONE);
|
179
|
+
\& }
|
180
|
+
\&
|
181
|
+
\& int
|
182
|
+
\& main (void)
|
183
|
+
\& {
|
184
|
+
\& // use the default event loop unless you have special needs
|
185
|
+
\& struct ev_loop *loop = ev_default_loop (0);
|
186
|
+
\&
|
187
|
+
\& // initialise an io watcher, then start it
|
188
|
+
\& // this one will watch for stdin to become readable
|
189
|
+
\& ev_io_init (&stdin_watcher, stdin_cb, /*STDIN_FILENO*/ 0, EV_READ);
|
190
|
+
\& ev_io_start (loop, &stdin_watcher);
|
191
|
+
\&
|
192
|
+
\& // initialise a timer watcher, then start it
|
193
|
+
\& // simple non\-repeating 5.5 second timeout
|
194
|
+
\& ev_timer_init (&timeout_watcher, timeout_cb, 5.5, 0.);
|
195
|
+
\& ev_timer_start (loop, &timeout_watcher);
|
196
|
+
\&
|
197
|
+
\& // now wait for events to arrive
|
198
|
+
\& ev_loop (loop, 0);
|
199
|
+
\&
|
200
|
+
\& // unloop was called, so exit
|
201
|
+
\& return 0;
|
202
|
+
\& }
|
203
|
+
.Ve
|
204
|
+
.SH "DESCRIPTION"
|
205
|
+
.IX Header "DESCRIPTION"
|
206
|
+
The newest version of this document is also available as an html-formatted
|
207
|
+
web page you might find easier to navigate when reading it for the first
|
208
|
+
time: <http://cvs.schmorp.de/libev/ev.html>.
|
209
|
+
.PP
|
210
|
+
Libev is an event loop: you register interest in certain events (such as a
|
211
|
+
file descriptor being readable or a timeout occurring), and it will manage
|
212
|
+
these event sources and provide your program with events.
|
213
|
+
.PP
|
214
|
+
To do this, it must take more or less complete control over your process
|
215
|
+
(or thread) by executing the \fIevent loop\fR handler, and will then
|
216
|
+
communicate events via a callback mechanism.
|
217
|
+
.PP
|
218
|
+
You register interest in certain events by registering so-called \fIevent
|
219
|
+
watchers\fR, which are relatively small C structures you initialise with the
|
220
|
+
details of the event, and then hand it over to libev by \fIstarting\fR the
|
221
|
+
watcher.
|
222
|
+
.Sh "\s-1FEATURES\s0"
|
223
|
+
.IX Subsection "FEATURES"
|
224
|
+
Libev supports \f(CW\*(C`select\*(C'\fR, \f(CW\*(C`poll\*(C'\fR, the Linux-specific \f(CW\*(C`epoll\*(C'\fR, the
|
225
|
+
BSD-specific \f(CW\*(C`kqueue\*(C'\fR and the Solaris-specific event port mechanisms
|
226
|
+
for file descriptor events (\f(CW\*(C`ev_io\*(C'\fR), the Linux \f(CW\*(C`inotify\*(C'\fR interface
|
227
|
+
(for \f(CW\*(C`ev_stat\*(C'\fR), relative timers (\f(CW\*(C`ev_timer\*(C'\fR), absolute timers
|
228
|
+
with customised rescheduling (\f(CW\*(C`ev_periodic\*(C'\fR), synchronous signals
|
229
|
+
(\f(CW\*(C`ev_signal\*(C'\fR), process status change events (\f(CW\*(C`ev_child\*(C'\fR), and event
|
230
|
+
watchers dealing with the event loop mechanism itself (\f(CW\*(C`ev_idle\*(C'\fR,
|
231
|
+
\&\f(CW\*(C`ev_embed\*(C'\fR, \f(CW\*(C`ev_prepare\*(C'\fR and \f(CW\*(C`ev_check\*(C'\fR watchers) as well as
|
232
|
+
file watchers (\f(CW\*(C`ev_stat\*(C'\fR) and even limited support for fork events
|
233
|
+
(\f(CW\*(C`ev_fork\*(C'\fR).
|
234
|
+
.PP
|
235
|
+
It also is quite fast (see this
|
236
|
+
benchmark comparing it to libevent
|
237
|
+
for example).
|
238
|
+
.Sh "\s-1CONVENTIONS\s0"
|
239
|
+
.IX Subsection "CONVENTIONS"
|
240
|
+
Libev is very configurable. In this manual the default (and most common)
|
241
|
+
configuration will be described, which supports multiple event loops. For
|
242
|
+
more info about various configuration options please have a look at
|
243
|
+
\&\fB\s-1EMBED\s0\fR section in this manual. If libev was configured without support
|
244
|
+
for multiple event loops, then all functions taking an initial argument of
|
245
|
+
name \f(CW\*(C`loop\*(C'\fR (which is always of type \f(CW\*(C`struct ev_loop *\*(C'\fR) will not have
|
246
|
+
this argument.
|
247
|
+
.Sh "\s-1TIME\s0 \s-1REPRESENTATION\s0"
|
248
|
+
.IX Subsection "TIME REPRESENTATION"
|
249
|
+
Libev represents time as a single floating point number, representing the
|
250
|
+
(fractional) number of seconds since the (\s-1POSIX\s0) epoch (somewhere near
|
251
|
+
the beginning of 1970, details are complicated, don't ask). This type is
|
252
|
+
called \f(CW\*(C`ev_tstamp\*(C'\fR, which is what you should use too. It usually aliases
|
253
|
+
to the \f(CW\*(C`double\*(C'\fR type in C, and when you need to do any calculations on
|
254
|
+
it, you should treat it as some floatingpoint value. Unlike the name
|
255
|
+
component \f(CW\*(C`stamp\*(C'\fR might indicate, it is also used for time differences
|
256
|
+
throughout libev.
|
257
|
+
.SH "GLOBAL FUNCTIONS"
|
258
|
+
.IX Header "GLOBAL FUNCTIONS"
|
259
|
+
These functions can be called anytime, even before initialising the
|
260
|
+
library in any way.
|
261
|
+
.IP "ev_tstamp ev_time ()" 4
|
262
|
+
.IX Item "ev_tstamp ev_time ()"
|
263
|
+
Returns the current time as libev would use it. Please note that the
|
264
|
+
\&\f(CW\*(C`ev_now\*(C'\fR function is usually faster and also often returns the timestamp
|
265
|
+
you actually want to know.
|
266
|
+
.IP "ev_sleep (ev_tstamp interval)" 4
|
267
|
+
.IX Item "ev_sleep (ev_tstamp interval)"
|
268
|
+
Sleep for the given interval: The current thread will be blocked until
|
269
|
+
either it is interrupted or the given time interval has passed. Basically
|
270
|
+
this is a subsecond-resolution \f(CW\*(C`sleep ()\*(C'\fR.
|
271
|
+
.IP "int ev_version_major ()" 4
|
272
|
+
.IX Item "int ev_version_major ()"
|
273
|
+
.PD 0
|
274
|
+
.IP "int ev_version_minor ()" 4
|
275
|
+
.IX Item "int ev_version_minor ()"
|
276
|
+
.PD
|
277
|
+
You can find out the major and minor \s-1ABI\s0 version numbers of the library
|
278
|
+
you linked against by calling the functions \f(CW\*(C`ev_version_major\*(C'\fR and
|
279
|
+
\&\f(CW\*(C`ev_version_minor\*(C'\fR. If you want, you can compare against the global
|
280
|
+
symbols \f(CW\*(C`EV_VERSION_MAJOR\*(C'\fR and \f(CW\*(C`EV_VERSION_MINOR\*(C'\fR, which specify the
|
281
|
+
version of the library your program was compiled against.
|
282
|
+
.Sp
|
283
|
+
These version numbers refer to the \s-1ABI\s0 version of the library, not the
|
284
|
+
release version.
|
285
|
+
.Sp
|
286
|
+
Usually, it's a good idea to terminate if the major versions mismatch,
|
287
|
+
as this indicates an incompatible change. Minor versions are usually
|
288
|
+
compatible to older versions, so a larger minor version alone is usually
|
289
|
+
not a problem.
|
290
|
+
.Sp
|
291
|
+
Example: Make sure we haven't accidentally been linked against the wrong
|
292
|
+
version.
|
293
|
+
.Sp
|
294
|
+
.Vb 3
|
295
|
+
\& assert (("libev version mismatch",
|
296
|
+
\& ev_version_major () == EV_VERSION_MAJOR
|
297
|
+
\& && ev_version_minor () >= EV_VERSION_MINOR));
|
298
|
+
.Ve
|
299
|
+
.IP "unsigned int ev_supported_backends ()" 4
|
300
|
+
.IX Item "unsigned int ev_supported_backends ()"
|
301
|
+
Return the set of all backends (i.e. their corresponding \f(CW\*(C`EV_BACKEND_*\*(C'\fR
|
302
|
+
value) compiled into this binary of libev (independent of their
|
303
|
+
availability on the system you are running on). See \f(CW\*(C`ev_default_loop\*(C'\fR for
|
304
|
+
a description of the set values.
|
305
|
+
.Sp
|
306
|
+
Example: make sure we have the epoll method, because yeah this is cool and
|
307
|
+
a must have and can we have a torrent of it please!!!11
|
308
|
+
.Sp
|
309
|
+
.Vb 2
|
310
|
+
\& assert (("sorry, no epoll, no sex",
|
311
|
+
\& ev_supported_backends () & EVBACKEND_EPOLL));
|
312
|
+
.Ve
|
313
|
+
.IP "unsigned int ev_recommended_backends ()" 4
|
314
|
+
.IX Item "unsigned int ev_recommended_backends ()"
|
315
|
+
Return the set of all backends compiled into this binary of libev and also
|
316
|
+
recommended for this platform. This set is often smaller than the one
|
317
|
+
returned by \f(CW\*(C`ev_supported_backends\*(C'\fR, as for example kqueue is broken on
|
318
|
+
most BSDs and will not be autodetected unless you explicitly request it
|
319
|
+
(assuming you know what you are doing). This is the set of backends that
|
320
|
+
libev will probe for if you specify no backends explicitly.
|
321
|
+
.IP "unsigned int ev_embeddable_backends ()" 4
|
322
|
+
.IX Item "unsigned int ev_embeddable_backends ()"
|
323
|
+
Returns the set of backends that are embeddable in other event loops. This
|
324
|
+
is the theoretical, all-platform, value. To find which backends
|
325
|
+
might be supported on the current system, you would need to look at
|
326
|
+
\&\f(CW\*(C`ev_embeddable_backends () & ev_supported_backends ()\*(C'\fR, likewise for
|
327
|
+
recommended ones.
|
328
|
+
.Sp
|
329
|
+
See the description of \f(CW\*(C`ev_embed\*(C'\fR watchers for more info.
|
330
|
+
.IP "ev_set_allocator (void *(*cb)(void *ptr, long size))" 4
|
331
|
+
.IX Item "ev_set_allocator (void *(*cb)(void *ptr, long size))"
|
332
|
+
Sets the allocation function to use (the prototype is similar \- the
|
333
|
+
semantics are identical to the \f(CW\*(C`realloc\*(C'\fR C89/SuS/POSIX function). It is
|
334
|
+
used to allocate and free memory (no surprises here). If it returns zero
|
335
|
+
when memory needs to be allocated (\f(CW\*(C`size != 0\*(C'\fR), the library might abort
|
336
|
+
or take some potentially destructive action.
|
337
|
+
.Sp
|
338
|
+
Since some systems (at least OpenBSD and Darwin) fail to implement
|
339
|
+
correct \f(CW\*(C`realloc\*(C'\fR semantics, libev will use a wrapper around the system
|
340
|
+
\&\f(CW\*(C`realloc\*(C'\fR and \f(CW\*(C`free\*(C'\fR functions by default.
|
341
|
+
.Sp
|
342
|
+
You could override this function in high-availability programs to, say,
|
343
|
+
free some memory if it cannot allocate memory, to use a special allocator,
|
344
|
+
or even to sleep a while and retry until some memory is available.
|
345
|
+
.Sp
|
346
|
+
Example: Replace the libev allocator with one that waits a bit and then
|
347
|
+
retries (example requires a standards-compliant \f(CW\*(C`realloc\*(C'\fR).
|
348
|
+
.Sp
|
349
|
+
.Vb 6
|
350
|
+
\& static void *
|
351
|
+
\& persistent_realloc (void *ptr, size_t size)
|
352
|
+
\& {
|
353
|
+
\& for (;;)
|
354
|
+
\& {
|
355
|
+
\& void *newptr = realloc (ptr, size);
|
356
|
+
\&
|
357
|
+
\& if (newptr)
|
358
|
+
\& return newptr;
|
359
|
+
\&
|
360
|
+
\& sleep (60);
|
361
|
+
\& }
|
362
|
+
\& }
|
363
|
+
\&
|
364
|
+
\& ...
|
365
|
+
\& ev_set_allocator (persistent_realloc);
|
366
|
+
.Ve
|
367
|
+
.IP "ev_set_syserr_cb (void (*cb)(const char *msg));" 4
|
368
|
+
.IX Item "ev_set_syserr_cb (void (*cb)(const char *msg));"
|
369
|
+
Set the callback function to call on a retryable syscall error (such
|
370
|
+
as failed select, poll, epoll_wait). The message is a printable string
|
371
|
+
indicating the system call or subsystem causing the problem. If this
|
372
|
+
callback is set, then libev will expect it to remedy the sitution, no
|
373
|
+
matter what, when it returns. That is, libev will generally retry the
|
374
|
+
requested operation, or, if the condition doesn't go away, do bad stuff
|
375
|
+
(such as abort).
|
376
|
+
.Sp
|
377
|
+
Example: This is basically the same thing that libev does internally, too.
|
378
|
+
.Sp
|
379
|
+
.Vb 6
|
380
|
+
\& static void
|
381
|
+
\& fatal_error (const char *msg)
|
382
|
+
\& {
|
383
|
+
\& perror (msg);
|
384
|
+
\& abort ();
|
385
|
+
\& }
|
386
|
+
\&
|
387
|
+
\& ...
|
388
|
+
\& ev_set_syserr_cb (fatal_error);
|
389
|
+
.Ve
|
390
|
+
.SH "FUNCTIONS CONTROLLING THE EVENT LOOP"
|
391
|
+
.IX Header "FUNCTIONS CONTROLLING THE EVENT LOOP"
|
392
|
+
An event loop is described by a \f(CW\*(C`struct ev_loop *\*(C'\fR. The library knows two
|
393
|
+
types of such loops, the \fIdefault\fR loop, which supports signals and child
|
394
|
+
events, and dynamically created loops which do not.
|
395
|
+
.IP "struct ev_loop *ev_default_loop (unsigned int flags)" 4
|
396
|
+
.IX Item "struct ev_loop *ev_default_loop (unsigned int flags)"
|
397
|
+
This will initialise the default event loop if it hasn't been initialised
|
398
|
+
yet and return it. If the default loop could not be initialised, returns
|
399
|
+
false. If it already was initialised it simply returns it (and ignores the
|
400
|
+
flags. If that is troubling you, check \f(CW\*(C`ev_backend ()\*(C'\fR afterwards).
|
401
|
+
.Sp
|
402
|
+
If you don't know what event loop to use, use the one returned from this
|
403
|
+
function.
|
404
|
+
.Sp
|
405
|
+
Note that this function is \fInot\fR thread-safe, so if you want to use it
|
406
|
+
from multiple threads, you have to lock (note also that this is unlikely,
|
407
|
+
as loops cannot bes hared easily between threads anyway).
|
408
|
+
.Sp
|
409
|
+
The default loop is the only loop that can handle \f(CW\*(C`ev_signal\*(C'\fR and
|
410
|
+
\&\f(CW\*(C`ev_child\*(C'\fR watchers, and to do this, it always registers a handler
|
411
|
+
for \f(CW\*(C`SIGCHLD\*(C'\fR. If this is a problem for your app you can either
|
412
|
+
create a dynamic loop with \f(CW\*(C`ev_loop_new\*(C'\fR that doesn't do that, or you
|
413
|
+
can simply overwrite the \f(CW\*(C`SIGCHLD\*(C'\fR signal handler \fIafter\fR calling
|
414
|
+
\&\f(CW\*(C`ev_default_init\*(C'\fR.
|
415
|
+
.Sp
|
416
|
+
The flags argument can be used to specify special behaviour or specific
|
417
|
+
backends to use, and is usually specified as \f(CW0\fR (or \f(CW\*(C`EVFLAG_AUTO\*(C'\fR).
|
418
|
+
.Sp
|
419
|
+
The following flags are supported:
|
420
|
+
.RS 4
|
421
|
+
.ie n .IP """EVFLAG_AUTO""" 4
|
422
|
+
.el .IP "\f(CWEVFLAG_AUTO\fR" 4
|
423
|
+
.IX Item "EVFLAG_AUTO"
|
424
|
+
The default flags value. Use this if you have no clue (it's the right
|
425
|
+
thing, believe me).
|
426
|
+
.ie n .IP """EVFLAG_NOENV""" 4
|
427
|
+
.el .IP "\f(CWEVFLAG_NOENV\fR" 4
|
428
|
+
.IX Item "EVFLAG_NOENV"
|
429
|
+
If this flag bit is ored into the flag value (or the program runs setuid
|
430
|
+
or setgid) then libev will \fInot\fR look at the environment variable
|
431
|
+
\&\f(CW\*(C`LIBEV_FLAGS\*(C'\fR. Otherwise (the default), this environment variable will
|
432
|
+
override the flags completely if it is found in the environment. This is
|
433
|
+
useful to try out specific backends to test their performance, or to work
|
434
|
+
around bugs.
|
435
|
+
.ie n .IP """EVFLAG_FORKCHECK""" 4
|
436
|
+
.el .IP "\f(CWEVFLAG_FORKCHECK\fR" 4
|
437
|
+
.IX Item "EVFLAG_FORKCHECK"
|
438
|
+
Instead of calling \f(CW\*(C`ev_default_fork\*(C'\fR or \f(CW\*(C`ev_loop_fork\*(C'\fR manually after
|
439
|
+
a fork, you can also make libev check for a fork in each iteration by
|
440
|
+
enabling this flag.
|
441
|
+
.Sp
|
442
|
+
This works by calling \f(CW\*(C`getpid ()\*(C'\fR on every iteration of the loop,
|
443
|
+
and thus this might slow down your event loop if you do a lot of loop
|
444
|
+
iterations and little real work, but is usually not noticeable (on my
|
445
|
+
GNU/Linux system for example, \f(CW\*(C`getpid\*(C'\fR is actually a simple 5\-insn sequence
|
446
|
+
without a syscall and thus \fIvery\fR fast, but my GNU/Linux system also has
|
447
|
+
\&\f(CW\*(C`pthread_atfork\*(C'\fR which is even faster).
|
448
|
+
.Sp
|
449
|
+
The big advantage of this flag is that you can forget about fork (and
|
450
|
+
forget about forgetting to tell libev about forking) when you use this
|
451
|
+
flag.
|
452
|
+
.Sp
|
453
|
+
This flag setting cannot be overriden or specified in the \f(CW\*(C`LIBEV_FLAGS\*(C'\fR
|
454
|
+
environment variable.
|
455
|
+
.ie n .IP """EVBACKEND_SELECT"" (value 1, portable select backend)" 4
|
456
|
+
.el .IP "\f(CWEVBACKEND_SELECT\fR (value 1, portable select backend)" 4
|
457
|
+
.IX Item "EVBACKEND_SELECT (value 1, portable select backend)"
|
458
|
+
This is your standard \fIselect\fR\|(2) backend. Not \fIcompletely\fR standard, as
|
459
|
+
libev tries to roll its own fd_set with no limits on the number of fds,
|
460
|
+
but if that fails, expect a fairly low limit on the number of fds when
|
461
|
+
using this backend. It doesn't scale too well (O(highest_fd)), but its
|
462
|
+
usually the fastest backend for a low number of (low-numbered :) fds.
|
463
|
+
.Sp
|
464
|
+
To get good performance out of this backend you need a high amount of
|
465
|
+
parallelity (most of the file descriptors should be busy). If you are
|
466
|
+
writing a server, you should \f(CW\*(C`accept ()\*(C'\fR in a loop to accept as many
|
467
|
+
connections as possible during one iteration. You might also want to have
|
468
|
+
a look at \f(CW\*(C`ev_set_io_collect_interval ()\*(C'\fR to increase the amount of
|
469
|
+
readyness notifications you get per iteration.
|
470
|
+
.ie n .IP """EVBACKEND_POLL"" (value 2, poll backend, available everywhere except on windows)" 4
|
471
|
+
.el .IP "\f(CWEVBACKEND_POLL\fR (value 2, poll backend, available everywhere except on windows)" 4
|
472
|
+
.IX Item "EVBACKEND_POLL (value 2, poll backend, available everywhere except on windows)"
|
473
|
+
And this is your standard \fIpoll\fR\|(2) backend. It's more complicated
|
474
|
+
than select, but handles sparse fds better and has no artificial
|
475
|
+
limit on the number of fds you can use (except it will slow down
|
476
|
+
considerably with a lot of inactive fds). It scales similarly to select,
|
477
|
+
i.e. O(total_fds). See the entry for \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR, above, for
|
478
|
+
performance tips.
|
479
|
+
.ie n .IP """EVBACKEND_EPOLL"" (value 4, Linux)" 4
|
480
|
+
.el .IP "\f(CWEVBACKEND_EPOLL\fR (value 4, Linux)" 4
|
481
|
+
.IX Item "EVBACKEND_EPOLL (value 4, Linux)"
|
482
|
+
For few fds, this backend is a bit little slower than poll and select,
|
483
|
+
but it scales phenomenally better. While poll and select usually scale
|
484
|
+
like O(total_fds) where n is the total number of fds (or the highest fd),
|
485
|
+
epoll scales either O(1) or O(active_fds). The epoll design has a number
|
486
|
+
of shortcomings, such as silently dropping events in some hard-to-detect
|
487
|
+
cases and requiring a syscall per fd change, no fork support and bad
|
488
|
+
support for dup.
|
489
|
+
.Sp
|
490
|
+
While stopping, setting and starting an I/O watcher in the same iteration
|
491
|
+
will result in some caching, there is still a syscall per such incident
|
492
|
+
(because the fd could point to a different file description now), so its
|
493
|
+
best to avoid that. Also, \f(CW\*(C`dup ()\*(C'\fR'ed file descriptors might not work
|
494
|
+
very well if you register events for both fds.
|
495
|
+
.Sp
|
496
|
+
Please note that epoll sometimes generates spurious notifications, so you
|
497
|
+
need to use non-blocking I/O or other means to avoid blocking when no data
|
498
|
+
(or space) is available.
|
499
|
+
.Sp
|
500
|
+
Best performance from this backend is achieved by not unregistering all
|
501
|
+
watchers for a file descriptor until it has been closed, if possible, i.e.
|
502
|
+
keep at least one watcher active per fd at all times.
|
503
|
+
.Sp
|
504
|
+
While nominally embeddeble in other event loops, this feature is broken in
|
505
|
+
all kernel versions tested so far.
|
506
|
+
.ie n .IP """EVBACKEND_KQUEUE"" (value 8, most \s-1BSD\s0 clones)" 4
|
507
|
+
.el .IP "\f(CWEVBACKEND_KQUEUE\fR (value 8, most \s-1BSD\s0 clones)" 4
|
508
|
+
.IX Item "EVBACKEND_KQUEUE (value 8, most BSD clones)"
|
509
|
+
Kqueue deserves special mention, as at the time of this writing, it
|
510
|
+
was broken on all BSDs except NetBSD (usually it doesn't work reliably
|
511
|
+
with anything but sockets and pipes, except on Darwin, where of course
|
512
|
+
it's completely useless). For this reason it's not being \*(L"autodetected\*(R"
|
513
|
+
unless you explicitly specify it explicitly in the flags (i.e. using
|
514
|
+
\&\f(CW\*(C`EVBACKEND_KQUEUE\*(C'\fR) or libev was compiled on a known-to-be-good (\-enough)
|
515
|
+
system like NetBSD.
|
516
|
+
.Sp
|
517
|
+
You still can embed kqueue into a normal poll or select backend and use it
|
518
|
+
only for sockets (after having made sure that sockets work with kqueue on
|
519
|
+
the target platform). See \f(CW\*(C`ev_embed\*(C'\fR watchers for more info.
|
520
|
+
.Sp
|
521
|
+
It scales in the same way as the epoll backend, but the interface to the
|
522
|
+
kernel is more efficient (which says nothing about its actual speed, of
|
523
|
+
course). While stopping, setting and starting an I/O watcher does never
|
524
|
+
cause an extra syscall as with \f(CW\*(C`EVBACKEND_EPOLL\*(C'\fR, it still adds up to
|
525
|
+
two event changes per incident, support for \f(CW\*(C`fork ()\*(C'\fR is very bad and it
|
526
|
+
drops fds silently in similarly hard-to-detect cases.
|
527
|
+
.Sp
|
528
|
+
This backend usually performs well under most conditions.
|
529
|
+
.Sp
|
530
|
+
While nominally embeddable in other event loops, this doesn't work
|
531
|
+
everywhere, so you might need to test for this. And since it is broken
|
532
|
+
almost everywhere, you should only use it when you have a lot of sockets
|
533
|
+
(for which it usually works), by embedding it into another event loop
|
534
|
+
(e.g. \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR) and using it only for
|
535
|
+
sockets.
|
536
|
+
.ie n .IP """EVBACKEND_DEVPOLL"" (value 16, Solaris 8)" 4
|
537
|
+
.el .IP "\f(CWEVBACKEND_DEVPOLL\fR (value 16, Solaris 8)" 4
|
538
|
+
.IX Item "EVBACKEND_DEVPOLL (value 16, Solaris 8)"
|
539
|
+
This is not implemented yet (and might never be, unless you send me an
|
540
|
+
implementation). According to reports, \f(CW\*(C`/dev/poll\*(C'\fR only supports sockets
|
541
|
+
and is not embeddable, which would limit the usefulness of this backend
|
542
|
+
immensely.
|
543
|
+
.ie n .IP """EVBACKEND_PORT"" (value 32, Solaris 10)" 4
|
544
|
+
.el .IP "\f(CWEVBACKEND_PORT\fR (value 32, Solaris 10)" 4
|
545
|
+
.IX Item "EVBACKEND_PORT (value 32, Solaris 10)"
|
546
|
+
This uses the Solaris 10 event port mechanism. As with everything on Solaris,
|
547
|
+
it's really slow, but it still scales very well (O(active_fds)).
|
548
|
+
.Sp
|
549
|
+
Please note that solaris event ports can deliver a lot of spurious
|
550
|
+
notifications, so you need to use non-blocking I/O or other means to avoid
|
551
|
+
blocking when no data (or space) is available.
|
552
|
+
.Sp
|
553
|
+
While this backend scales well, it requires one system call per active
|
554
|
+
file descriptor per loop iteration. For small and medium numbers of file
|
555
|
+
descriptors a \*(L"slow\*(R" \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR backend
|
556
|
+
might perform better.
|
557
|
+
.Sp
|
558
|
+
On the positive side, ignoring the spurious readyness notifications, this
|
559
|
+
backend actually performed to specification in all tests and is fully
|
560
|
+
embeddable, which is a rare feat among the OS-specific backends.
|
561
|
+
.ie n .IP """EVBACKEND_ALL""" 4
|
562
|
+
.el .IP "\f(CWEVBACKEND_ALL\fR" 4
|
563
|
+
.IX Item "EVBACKEND_ALL"
|
564
|
+
Try all backends (even potentially broken ones that wouldn't be tried
|
565
|
+
with \f(CW\*(C`EVFLAG_AUTO\*(C'\fR). Since this is a mask, you can do stuff such as
|
566
|
+
\&\f(CW\*(C`EVBACKEND_ALL & ~EVBACKEND_KQUEUE\*(C'\fR.
|
567
|
+
.Sp
|
568
|
+
It is definitely not recommended to use this flag.
|
569
|
+
.RE
|
570
|
+
.RS 4
|
571
|
+
.Sp
|
572
|
+
If one or more of these are ored into the flags value, then only these
|
573
|
+
backends will be tried (in the reverse order as listed here). If none are
|
574
|
+
specified, all backends in \f(CW\*(C`ev_recommended_backends ()\*(C'\fR will be tried.
|
575
|
+
.Sp
|
576
|
+
The most typical usage is like this:
|
577
|
+
.Sp
|
578
|
+
.Vb 2
|
579
|
+
\& if (!ev_default_loop (0))
|
580
|
+
\& fatal ("could not initialise libev, bad $LIBEV_FLAGS in environment?");
|
581
|
+
.Ve
|
582
|
+
.Sp
|
583
|
+
Restrict libev to the select and poll backends, and do not allow
|
584
|
+
environment settings to be taken into account:
|
585
|
+
.Sp
|
586
|
+
.Vb 1
|
587
|
+
\& ev_default_loop (EVBACKEND_POLL | EVBACKEND_SELECT | EVFLAG_NOENV);
|
588
|
+
.Ve
|
589
|
+
.Sp
|
590
|
+
Use whatever libev has to offer, but make sure that kqueue is used if
|
591
|
+
available (warning, breaks stuff, best use only with your own private
|
592
|
+
event loop and only if you know the \s-1OS\s0 supports your types of fds):
|
593
|
+
.Sp
|
594
|
+
.Vb 1
|
595
|
+
\& ev_default_loop (ev_recommended_backends () | EVBACKEND_KQUEUE);
|
596
|
+
.Ve
|
597
|
+
.RE
|
598
|
+
.IP "struct ev_loop *ev_loop_new (unsigned int flags)" 4
|
599
|
+
.IX Item "struct ev_loop *ev_loop_new (unsigned int flags)"
|
600
|
+
Similar to \f(CW\*(C`ev_default_loop\*(C'\fR, but always creates a new event loop that is
|
601
|
+
always distinct from the default loop. Unlike the default loop, it cannot
|
602
|
+
handle signal and child watchers, and attempts to do so will be greeted by
|
603
|
+
undefined behaviour (or a failed assertion if assertions are enabled).
|
604
|
+
.Sp
|
605
|
+
Note that this function \fIis\fR thread-safe, and the recommended way to use
|
606
|
+
libev with threads is indeed to create one loop per thread, and using the
|
607
|
+
default loop in the \*(L"main\*(R" or \*(L"initial\*(R" thread.
|
608
|
+
.Sp
|
609
|
+
Example: Try to create a event loop that uses epoll and nothing else.
|
610
|
+
.Sp
|
611
|
+
.Vb 3
|
612
|
+
\& struct ev_loop *epoller = ev_loop_new (EVBACKEND_EPOLL | EVFLAG_NOENV);
|
613
|
+
\& if (!epoller)
|
614
|
+
\& fatal ("no epoll found here, maybe it hides under your chair");
|
615
|
+
.Ve
|
616
|
+
.IP "ev_default_destroy ()" 4
|
617
|
+
.IX Item "ev_default_destroy ()"
|
618
|
+
Destroys the default loop again (frees all memory and kernel state
|
619
|
+
etc.). None of the active event watchers will be stopped in the normal
|
620
|
+
sense, so e.g. \f(CW\*(C`ev_is_active\*(C'\fR might still return true. It is your
|
621
|
+
responsibility to either stop all watchers cleanly yoursef \fIbefore\fR
|
622
|
+
calling this function, or cope with the fact afterwards (which is usually
|
623
|
+
the easiest thing, you can just ignore the watchers and/or \f(CW\*(C`free ()\*(C'\fR them
|
624
|
+
for example).
|
625
|
+
.Sp
|
626
|
+
Note that certain global state, such as signal state, will not be freed by
|
627
|
+
this function, and related watchers (such as signal and child watchers)
|
628
|
+
would need to be stopped manually.
|
629
|
+
.Sp
|
630
|
+
In general it is not advisable to call this function except in the
|
631
|
+
rare occasion where you really need to free e.g. the signal handling
|
632
|
+
pipe fds. If you need dynamically allocated loops it is better to use
|
633
|
+
\&\f(CW\*(C`ev_loop_new\*(C'\fR and \f(CW\*(C`ev_loop_destroy\*(C'\fR).
|
634
|
+
.IP "ev_loop_destroy (loop)" 4
|
635
|
+
.IX Item "ev_loop_destroy (loop)"
|
636
|
+
Like \f(CW\*(C`ev_default_destroy\*(C'\fR, but destroys an event loop created by an
|
637
|
+
earlier call to \f(CW\*(C`ev_loop_new\*(C'\fR.
|
638
|
+
.IP "ev_default_fork ()" 4
|
639
|
+
.IX Item "ev_default_fork ()"
|
640
|
+
This function sets a flag that causes subsequent \f(CW\*(C`ev_loop\*(C'\fR iterations
|
641
|
+
to reinitialise the kernel state for backends that have one. Despite the
|
642
|
+
name, you can call it anytime, but it makes most sense after forking, in
|
643
|
+
the child process (or both child and parent, but that again makes little
|
644
|
+
sense). You \fImust\fR call it in the child before using any of the libev
|
645
|
+
functions, and it will only take effect at the next \f(CW\*(C`ev_loop\*(C'\fR iteration.
|
646
|
+
.Sp
|
647
|
+
On the other hand, you only need to call this function in the child
|
648
|
+
process if and only if you want to use the event library in the child. If
|
649
|
+
you just fork+exec, you don't have to call it at all.
|
650
|
+
.Sp
|
651
|
+
The function itself is quite fast and it's usually not a problem to call
|
652
|
+
it just in case after a fork. To make this easy, the function will fit in
|
653
|
+
quite nicely into a call to \f(CW\*(C`pthread_atfork\*(C'\fR:
|
654
|
+
.Sp
|
655
|
+
.Vb 1
|
656
|
+
\& pthread_atfork (0, 0, ev_default_fork);
|
657
|
+
.Ve
|
658
|
+
.IP "ev_loop_fork (loop)" 4
|
659
|
+
.IX Item "ev_loop_fork (loop)"
|
660
|
+
Like \f(CW\*(C`ev_default_fork\*(C'\fR, but acts on an event loop created by
|
661
|
+
\&\f(CW\*(C`ev_loop_new\*(C'\fR. Yes, you have to call this on every allocated event loop
|
662
|
+
after fork, and how you do this is entirely your own problem.
|
663
|
+
.IP "int ev_is_default_loop (loop)" 4
|
664
|
+
.IX Item "int ev_is_default_loop (loop)"
|
665
|
+
Returns true when the given loop actually is the default loop, false otherwise.
|
666
|
+
.IP "unsigned int ev_loop_count (loop)" 4
|
667
|
+
.IX Item "unsigned int ev_loop_count (loop)"
|
668
|
+
Returns the count of loop iterations for the loop, which is identical to
|
669
|
+
the number of times libev did poll for new events. It starts at \f(CW0\fR and
|
670
|
+
happily wraps around with enough iterations.
|
671
|
+
.Sp
|
672
|
+
This value can sometimes be useful as a generation counter of sorts (it
|
673
|
+
\&\*(L"ticks\*(R" the number of loop iterations), as it roughly corresponds with
|
674
|
+
\&\f(CW\*(C`ev_prepare\*(C'\fR and \f(CW\*(C`ev_check\*(C'\fR calls.
|
675
|
+
.IP "unsigned int ev_backend (loop)" 4
|
676
|
+
.IX Item "unsigned int ev_backend (loop)"
|
677
|
+
Returns one of the \f(CW\*(C`EVBACKEND_*\*(C'\fR flags indicating the event backend in
|
678
|
+
use.
|
679
|
+
.IP "ev_tstamp ev_now (loop)" 4
|
680
|
+
.IX Item "ev_tstamp ev_now (loop)"
|
681
|
+
Returns the current \*(L"event loop time\*(R", which is the time the event loop
|
682
|
+
received events and started processing them. This timestamp does not
|
683
|
+
change as long as callbacks are being processed, and this is also the base
|
684
|
+
time used for relative timers. You can treat it as the timestamp of the
|
685
|
+
event occurring (or more correctly, libev finding out about it).
|
686
|
+
.IP "ev_loop (loop, int flags)" 4
|
687
|
+
.IX Item "ev_loop (loop, int flags)"
|
688
|
+
Finally, this is it, the event handler. This function usually is called
|
689
|
+
after you initialised all your watchers and you want to start handling
|
690
|
+
events.
|
691
|
+
.Sp
|
692
|
+
If the flags argument is specified as \f(CW0\fR, it will not return until
|
693
|
+
either no event watchers are active anymore or \f(CW\*(C`ev_unloop\*(C'\fR was called.
|
694
|
+
.Sp
|
695
|
+
Please note that an explicit \f(CW\*(C`ev_unloop\*(C'\fR is usually better than
|
696
|
+
relying on all watchers to be stopped when deciding when a program has
|
697
|
+
finished (especially in interactive programs), but having a program that
|
698
|
+
automatically loops as long as it has to and no longer by virtue of
|
699
|
+
relying on its watchers stopping correctly is a thing of beauty.
|
700
|
+
.Sp
|
701
|
+
A flags value of \f(CW\*(C`EVLOOP_NONBLOCK\*(C'\fR will look for new events, will handle
|
702
|
+
those events and any outstanding ones, but will not block your process in
|
703
|
+
case there are no events and will return after one iteration of the loop.
|
704
|
+
.Sp
|
705
|
+
A flags value of \f(CW\*(C`EVLOOP_ONESHOT\*(C'\fR will look for new events (waiting if
|
706
|
+
neccessary) and will handle those and any outstanding ones. It will block
|
707
|
+
your process until at least one new event arrives, and will return after
|
708
|
+
one iteration of the loop. This is useful if you are waiting for some
|
709
|
+
external event in conjunction with something not expressible using other
|
710
|
+
libev watchers. However, a pair of \f(CW\*(C`ev_prepare\*(C'\fR/\f(CW\*(C`ev_check\*(C'\fR watchers is
|
711
|
+
usually a better approach for this kind of thing.
|
712
|
+
.Sp
|
713
|
+
Here are the gory details of what \f(CW\*(C`ev_loop\*(C'\fR does:
|
714
|
+
.Sp
|
715
|
+
.Vb 10
|
716
|
+
\& \- Before the first iteration, call any pending watchers.
|
717
|
+
\& * If EVFLAG_FORKCHECK was used, check for a fork.
|
718
|
+
\& \- If a fork was detected, queue and call all fork watchers.
|
719
|
+
\& \- Queue and call all prepare watchers.
|
720
|
+
\& \- If we have been forked, recreate the kernel state.
|
721
|
+
\& \- Update the kernel state with all outstanding changes.
|
722
|
+
\& \- Update the "event loop time".
|
723
|
+
\& \- Calculate for how long to sleep or block, if at all
|
724
|
+
\& (active idle watchers, EVLOOP_NONBLOCK or not having
|
725
|
+
\& any active watchers at all will result in not sleeping).
|
726
|
+
\& \- Sleep if the I/O and timer collect interval say so.
|
727
|
+
\& \- Block the process, waiting for any events.
|
728
|
+
\& \- Queue all outstanding I/O (fd) events.
|
729
|
+
\& \- Update the "event loop time" and do time jump handling.
|
730
|
+
\& \- Queue all outstanding timers.
|
731
|
+
\& \- Queue all outstanding periodics.
|
732
|
+
\& \- If no events are pending now, queue all idle watchers.
|
733
|
+
\& \- Queue all check watchers.
|
734
|
+
\& \- Call all queued watchers in reverse order (i.e. check watchers first).
|
735
|
+
\& Signals and child watchers are implemented as I/O watchers, and will
|
736
|
+
\& be handled here by queueing them when their watcher gets executed.
|
737
|
+
\& \- If ev_unloop has been called, or EVLOOP_ONESHOT or EVLOOP_NONBLOCK
|
738
|
+
\& were used, or there are no active watchers, return, otherwise
|
739
|
+
\& continue with step *.
|
740
|
+
.Ve
|
741
|
+
.Sp
|
742
|
+
Example: Queue some jobs and then loop until no events are outstanding
|
743
|
+
anymore.
|
744
|
+
.Sp
|
745
|
+
.Vb 4
|
746
|
+
\& ... queue jobs here, make sure they register event watchers as long
|
747
|
+
\& ... as they still have work to do (even an idle watcher will do..)
|
748
|
+
\& ev_loop (my_loop, 0);
|
749
|
+
\& ... jobs done. yeah!
|
750
|
+
.Ve
|
751
|
+
.IP "ev_unloop (loop, how)" 4
|
752
|
+
.IX Item "ev_unloop (loop, how)"
|
753
|
+
Can be used to make a call to \f(CW\*(C`ev_loop\*(C'\fR return early (but only after it
|
754
|
+
has processed all outstanding events). The \f(CW\*(C`how\*(C'\fR argument must be either
|
755
|
+
\&\f(CW\*(C`EVUNLOOP_ONE\*(C'\fR, which will make the innermost \f(CW\*(C`ev_loop\*(C'\fR call return, or
|
756
|
+
\&\f(CW\*(C`EVUNLOOP_ALL\*(C'\fR, which will make all nested \f(CW\*(C`ev_loop\*(C'\fR calls return.
|
757
|
+
.Sp
|
758
|
+
This \*(L"unloop state\*(R" will be cleared when entering \f(CW\*(C`ev_loop\*(C'\fR again.
|
759
|
+
.IP "ev_ref (loop)" 4
|
760
|
+
.IX Item "ev_ref (loop)"
|
761
|
+
.PD 0
|
762
|
+
.IP "ev_unref (loop)" 4
|
763
|
+
.IX Item "ev_unref (loop)"
|
764
|
+
.PD
|
765
|
+
Ref/unref can be used to add or remove a reference count on the event
|
766
|
+
loop: Every watcher keeps one reference, and as long as the reference
|
767
|
+
count is nonzero, \f(CW\*(C`ev_loop\*(C'\fR will not return on its own. If you have
|
768
|
+
a watcher you never unregister that should not keep \f(CW\*(C`ev_loop\*(C'\fR from
|
769
|
+
returning, \fIev_unref()\fR after starting, and \fIev_ref()\fR before stopping it. For
|
770
|
+
example, libev itself uses this for its internal signal pipe: It is not
|
771
|
+
visible to the libev user and should not keep \f(CW\*(C`ev_loop\*(C'\fR from exiting if
|
772
|
+
no event watchers registered by it are active. It is also an excellent
|
773
|
+
way to do this for generic recurring timers or from within third-party
|
774
|
+
libraries. Just remember to \fIunref after start\fR and \fIref before stop\fR
|
775
|
+
(but only if the watcher wasn't active before, or was active before,
|
776
|
+
respectively).
|
777
|
+
.Sp
|
778
|
+
Example: Create a signal watcher, but keep it from keeping \f(CW\*(C`ev_loop\*(C'\fR
|
779
|
+
running when nothing else is active.
|
780
|
+
.Sp
|
781
|
+
.Vb 4
|
782
|
+
\& struct ev_signal exitsig;
|
783
|
+
\& ev_signal_init (&exitsig, sig_cb, SIGINT);
|
784
|
+
\& ev_signal_start (loop, &exitsig);
|
785
|
+
\& evf_unref (loop);
|
786
|
+
.Ve
|
787
|
+
.Sp
|
788
|
+
Example: For some weird reason, unregister the above signal handler again.
|
789
|
+
.Sp
|
790
|
+
.Vb 2
|
791
|
+
\& ev_ref (loop);
|
792
|
+
\& ev_signal_stop (loop, &exitsig);
|
793
|
+
.Ve
|
794
|
+
.IP "ev_set_io_collect_interval (loop, ev_tstamp interval)" 4
|
795
|
+
.IX Item "ev_set_io_collect_interval (loop, ev_tstamp interval)"
|
796
|
+
.PD 0
|
797
|
+
.IP "ev_set_timeout_collect_interval (loop, ev_tstamp interval)" 4
|
798
|
+
.IX Item "ev_set_timeout_collect_interval (loop, ev_tstamp interval)"
|
799
|
+
.PD
|
800
|
+
These advanced functions influence the time that libev will spend waiting
|
801
|
+
for events. Both are by default \f(CW0\fR, meaning that libev will try to
|
802
|
+
invoke timer/periodic callbacks and I/O callbacks with minimum latency.
|
803
|
+
.Sp
|
804
|
+
Setting these to a higher value (the \f(CW\*(C`interval\*(C'\fR \fImust\fR be >= \f(CW0\fR)
|
805
|
+
allows libev to delay invocation of I/O and timer/periodic callbacks to
|
806
|
+
increase efficiency of loop iterations.
|
807
|
+
.Sp
|
808
|
+
The background is that sometimes your program runs just fast enough to
|
809
|
+
handle one (or very few) event(s) per loop iteration. While this makes
|
810
|
+
the program responsive, it also wastes a lot of \s-1CPU\s0 time to poll for new
|
811
|
+
events, especially with backends like \f(CW\*(C`select ()\*(C'\fR which have a high
|
812
|
+
overhead for the actual polling but can deliver many events at once.
|
813
|
+
.Sp
|
814
|
+
By setting a higher \fIio collect interval\fR you allow libev to spend more
|
815
|
+
time collecting I/O events, so you can handle more events per iteration,
|
816
|
+
at the cost of increasing latency. Timeouts (both \f(CW\*(C`ev_periodic\*(C'\fR and
|
817
|
+
\&\f(CW\*(C`ev_timer\*(C'\fR) will be not affected. Setting this to a non-null value will
|
818
|
+
introduce an additional \f(CW\*(C`ev_sleep ()\*(C'\fR call into most loop iterations.
|
819
|
+
.Sp
|
820
|
+
Likewise, by setting a higher \fItimeout collect interval\fR you allow libev
|
821
|
+
to spend more time collecting timeouts, at the expense of increased
|
822
|
+
latency (the watcher callback will be called later). \f(CW\*(C`ev_io\*(C'\fR watchers
|
823
|
+
will not be affected. Setting this to a non-null value will not introduce
|
824
|
+
any overhead in libev.
|
825
|
+
.Sp
|
826
|
+
Many (busy) programs can usually benefit by setting the io collect
|
827
|
+
interval to a value near \f(CW0.1\fR or so, which is often enough for
|
828
|
+
interactive servers (of course not for games), likewise for timeouts. It
|
829
|
+
usually doesn't make much sense to set it to a lower value than \f(CW0.01\fR,
|
830
|
+
as this approsaches the timing granularity of most systems.
|
831
|
+
.SH "ANATOMY OF A WATCHER"
|
832
|
+
.IX Header "ANATOMY OF A WATCHER"
|
833
|
+
A watcher is a structure that you create and register to record your
|
834
|
+
interest in some event. For instance, if you want to wait for \s-1STDIN\s0 to
|
835
|
+
become readable, you would create an \f(CW\*(C`ev_io\*(C'\fR watcher for that:
|
836
|
+
.PP
|
837
|
+
.Vb 5
|
838
|
+
\& static void my_cb (struct ev_loop *loop, struct ev_io *w, int revents)
|
839
|
+
\& {
|
840
|
+
\& ev_io_stop (w);
|
841
|
+
\& ev_unloop (loop, EVUNLOOP_ALL);
|
842
|
+
\& }
|
843
|
+
\&
|
844
|
+
\& struct ev_loop *loop = ev_default_loop (0);
|
845
|
+
\& struct ev_io stdin_watcher;
|
846
|
+
\& ev_init (&stdin_watcher, my_cb);
|
847
|
+
\& ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ);
|
848
|
+
\& ev_io_start (loop, &stdin_watcher);
|
849
|
+
\& ev_loop (loop, 0);
|
850
|
+
.Ve
|
851
|
+
.PP
|
852
|
+
As you can see, you are responsible for allocating the memory for your
|
853
|
+
watcher structures (and it is usually a bad idea to do this on the stack,
|
854
|
+
although this can sometimes be quite valid).
|
855
|
+
.PP
|
856
|
+
Each watcher structure must be initialised by a call to \f(CW\*(C`ev_init
|
857
|
+
(watcher *, callback)\*(C'\fR, which expects a callback to be provided. This
|
858
|
+
callback gets invoked each time the event occurs (or, in the case of io
|
859
|
+
watchers, each time the event loop detects that the file descriptor given
|
860
|
+
is readable and/or writable).
|
861
|
+
.PP
|
862
|
+
Each watcher type has its own \f(CW\*(C`ev_<type>_set (watcher *, ...)\*(C'\fR macro
|
863
|
+
with arguments specific to this watcher type. There is also a macro
|
864
|
+
to combine initialisation and setting in one call: \f(CW\*(C`ev_<type>_init
|
865
|
+
(watcher *, callback, ...)\*(C'\fR.
|
866
|
+
.PP
|
867
|
+
To make the watcher actually watch out for events, you have to start it
|
868
|
+
with a watcher-specific start function (\f(CW\*(C`ev_<type>_start (loop, watcher
|
869
|
+
*)\*(C'\fR), and you can stop watching for events at any time by calling the
|
870
|
+
corresponding stop function (\f(CW\*(C`ev_<type>_stop (loop, watcher *)\*(C'\fR.
|
871
|
+
.PP
|
872
|
+
As long as your watcher is active (has been started but not stopped) you
|
873
|
+
must not touch the values stored in it. Most specifically you must never
|
874
|
+
reinitialise it or call its \f(CW\*(C`set\*(C'\fR macro.
|
875
|
+
.PP
|
876
|
+
Each and every callback receives the event loop pointer as first, the
|
877
|
+
registered watcher structure as second, and a bitset of received events as
|
878
|
+
third argument.
|
879
|
+
.PP
|
880
|
+
The received events usually include a single bit per event type received
|
881
|
+
(you can receive multiple events at the same time). The possible bit masks
|
882
|
+
are:
|
883
|
+
.ie n .IP """EV_READ""" 4
|
884
|
+
.el .IP "\f(CWEV_READ\fR" 4
|
885
|
+
.IX Item "EV_READ"
|
886
|
+
.PD 0
|
887
|
+
.ie n .IP """EV_WRITE""" 4
|
888
|
+
.el .IP "\f(CWEV_WRITE\fR" 4
|
889
|
+
.IX Item "EV_WRITE"
|
890
|
+
.PD
|
891
|
+
The file descriptor in the \f(CW\*(C`ev_io\*(C'\fR watcher has become readable and/or
|
892
|
+
writable.
|
893
|
+
.ie n .IP """EV_TIMEOUT""" 4
|
894
|
+
.el .IP "\f(CWEV_TIMEOUT\fR" 4
|
895
|
+
.IX Item "EV_TIMEOUT"
|
896
|
+
The \f(CW\*(C`ev_timer\*(C'\fR watcher has timed out.
|
897
|
+
.ie n .IP """EV_PERIODIC""" 4
|
898
|
+
.el .IP "\f(CWEV_PERIODIC\fR" 4
|
899
|
+
.IX Item "EV_PERIODIC"
|
900
|
+
The \f(CW\*(C`ev_periodic\*(C'\fR watcher has timed out.
|
901
|
+
.ie n .IP """EV_SIGNAL""" 4
|
902
|
+
.el .IP "\f(CWEV_SIGNAL\fR" 4
|
903
|
+
.IX Item "EV_SIGNAL"
|
904
|
+
The signal specified in the \f(CW\*(C`ev_signal\*(C'\fR watcher has been received by a thread.
|
905
|
+
.ie n .IP """EV_CHILD""" 4
|
906
|
+
.el .IP "\f(CWEV_CHILD\fR" 4
|
907
|
+
.IX Item "EV_CHILD"
|
908
|
+
The pid specified in the \f(CW\*(C`ev_child\*(C'\fR watcher has received a status change.
|
909
|
+
.ie n .IP """EV_STAT""" 4
|
910
|
+
.el .IP "\f(CWEV_STAT\fR" 4
|
911
|
+
.IX Item "EV_STAT"
|
912
|
+
The path specified in the \f(CW\*(C`ev_stat\*(C'\fR watcher changed its attributes somehow.
|
913
|
+
.ie n .IP """EV_IDLE""" 4
|
914
|
+
.el .IP "\f(CWEV_IDLE\fR" 4
|
915
|
+
.IX Item "EV_IDLE"
|
916
|
+
The \f(CW\*(C`ev_idle\*(C'\fR watcher has determined that you have nothing better to do.
|
917
|
+
.ie n .IP """EV_PREPARE""" 4
|
918
|
+
.el .IP "\f(CWEV_PREPARE\fR" 4
|
919
|
+
.IX Item "EV_PREPARE"
|
920
|
+
.PD 0
|
921
|
+
.ie n .IP """EV_CHECK""" 4
|
922
|
+
.el .IP "\f(CWEV_CHECK\fR" 4
|
923
|
+
.IX Item "EV_CHECK"
|
924
|
+
.PD
|
925
|
+
All \f(CW\*(C`ev_prepare\*(C'\fR watchers are invoked just \fIbefore\fR \f(CW\*(C`ev_loop\*(C'\fR starts
|
926
|
+
to gather new events, and all \f(CW\*(C`ev_check\*(C'\fR watchers are invoked just after
|
927
|
+
\&\f(CW\*(C`ev_loop\*(C'\fR has gathered them, but before it invokes any callbacks for any
|
928
|
+
received events. Callbacks of both watcher types can start and stop as
|
929
|
+
many watchers as they want, and all of them will be taken into account
|
930
|
+
(for example, a \f(CW\*(C`ev_prepare\*(C'\fR watcher might start an idle watcher to keep
|
931
|
+
\&\f(CW\*(C`ev_loop\*(C'\fR from blocking).
|
932
|
+
.ie n .IP """EV_EMBED""" 4
|
933
|
+
.el .IP "\f(CWEV_EMBED\fR" 4
|
934
|
+
.IX Item "EV_EMBED"
|
935
|
+
The embedded event loop specified in the \f(CW\*(C`ev_embed\*(C'\fR watcher needs attention.
|
936
|
+
.ie n .IP """EV_FORK""" 4
|
937
|
+
.el .IP "\f(CWEV_FORK\fR" 4
|
938
|
+
.IX Item "EV_FORK"
|
939
|
+
The event loop has been resumed in the child process after fork (see
|
940
|
+
\&\f(CW\*(C`ev_fork\*(C'\fR).
|
941
|
+
.ie n .IP """EV_ASYNC""" 4
|
942
|
+
.el .IP "\f(CWEV_ASYNC\fR" 4
|
943
|
+
.IX Item "EV_ASYNC"
|
944
|
+
The given async watcher has been asynchronously notified (see \f(CW\*(C`ev_async\*(C'\fR).
|
945
|
+
.ie n .IP """EV_ERROR""" 4
|
946
|
+
.el .IP "\f(CWEV_ERROR\fR" 4
|
947
|
+
.IX Item "EV_ERROR"
|
948
|
+
An unspecified error has occured, the watcher has been stopped. This might
|
949
|
+
happen because the watcher could not be properly started because libev
|
950
|
+
ran out of memory, a file descriptor was found to be closed or any other
|
951
|
+
problem. You best act on it by reporting the problem and somehow coping
|
952
|
+
with the watcher being stopped.
|
953
|
+
.Sp
|
954
|
+
Libev will usually signal a few \*(L"dummy\*(R" events together with an error,
|
955
|
+
for example it might indicate that a fd is readable or writable, and if
|
956
|
+
your callbacks is well-written it can just attempt the operation and cope
|
957
|
+
with the error from \fIread()\fR or \fIwrite()\fR. This will not work in multithreaded
|
958
|
+
programs, though, so beware.
|
959
|
+
.Sh "\s-1GENERIC\s0 \s-1WATCHER\s0 \s-1FUNCTIONS\s0"
|
960
|
+
.IX Subsection "GENERIC WATCHER FUNCTIONS"
|
961
|
+
In the following description, \f(CW\*(C`TYPE\*(C'\fR stands for the watcher type,
|
962
|
+
e.g. \f(CW\*(C`timer\*(C'\fR for \f(CW\*(C`ev_timer\*(C'\fR watchers and \f(CW\*(C`io\*(C'\fR for \f(CW\*(C`ev_io\*(C'\fR watchers.
|
963
|
+
.ie n .IP """ev_init"" (ev_TYPE *watcher, callback)" 4
|
964
|
+
.el .IP "\f(CWev_init\fR (ev_TYPE *watcher, callback)" 4
|
965
|
+
.IX Item "ev_init (ev_TYPE *watcher, callback)"
|
966
|
+
This macro initialises the generic portion of a watcher. The contents
|
967
|
+
of the watcher object can be arbitrary (so \f(CW\*(C`malloc\*(C'\fR will do). Only
|
968
|
+
the generic parts of the watcher are initialised, you \fIneed\fR to call
|
969
|
+
the type-specific \f(CW\*(C`ev_TYPE_set\*(C'\fR macro afterwards to initialise the
|
970
|
+
type-specific parts. For each type there is also a \f(CW\*(C`ev_TYPE_init\*(C'\fR macro
|
971
|
+
which rolls both calls into one.
|
972
|
+
.Sp
|
973
|
+
You can reinitialise a watcher at any time as long as it has been stopped
|
974
|
+
(or never started) and there are no pending events outstanding.
|
975
|
+
.Sp
|
976
|
+
The callback is always of type \f(CW\*(C`void (*)(ev_loop *loop, ev_TYPE *watcher,
|
977
|
+
int revents)\*(C'\fR.
|
978
|
+
.ie n .IP """ev_TYPE_set"" (ev_TYPE *, [args])" 4
|
979
|
+
.el .IP "\f(CWev_TYPE_set\fR (ev_TYPE *, [args])" 4
|
980
|
+
.IX Item "ev_TYPE_set (ev_TYPE *, [args])"
|
981
|
+
This macro initialises the type-specific parts of a watcher. You need to
|
982
|
+
call \f(CW\*(C`ev_init\*(C'\fR at least once before you call this macro, but you can
|
983
|
+
call \f(CW\*(C`ev_TYPE_set\*(C'\fR any number of times. You must not, however, call this
|
984
|
+
macro on a watcher that is active (it can be pending, however, which is a
|
985
|
+
difference to the \f(CW\*(C`ev_init\*(C'\fR macro).
|
986
|
+
.Sp
|
987
|
+
Although some watcher types do not have type-specific arguments
|
988
|
+
(e.g. \f(CW\*(C`ev_prepare\*(C'\fR) you still need to call its \f(CW\*(C`set\*(C'\fR macro.
|
989
|
+
.ie n .IP """ev_TYPE_init"" (ev_TYPE *watcher, callback, [args])" 4
|
990
|
+
.el .IP "\f(CWev_TYPE_init\fR (ev_TYPE *watcher, callback, [args])" 4
|
991
|
+
.IX Item "ev_TYPE_init (ev_TYPE *watcher, callback, [args])"
|
992
|
+
This convinience macro rolls both \f(CW\*(C`ev_init\*(C'\fR and \f(CW\*(C`ev_TYPE_set\*(C'\fR macro
|
993
|
+
calls into a single call. This is the most convinient method to initialise
|
994
|
+
a watcher. The same limitations apply, of course.
|
995
|
+
.ie n .IP """ev_TYPE_start"" (loop *, ev_TYPE *watcher)" 4
|
996
|
+
.el .IP "\f(CWev_TYPE_start\fR (loop *, ev_TYPE *watcher)" 4
|
997
|
+
.IX Item "ev_TYPE_start (loop *, ev_TYPE *watcher)"
|
998
|
+
Starts (activates) the given watcher. Only active watchers will receive
|
999
|
+
events. If the watcher is already active nothing will happen.
|
1000
|
+
.ie n .IP """ev_TYPE_stop"" (loop *, ev_TYPE *watcher)" 4
|
1001
|
+
.el .IP "\f(CWev_TYPE_stop\fR (loop *, ev_TYPE *watcher)" 4
|
1002
|
+
.IX Item "ev_TYPE_stop (loop *, ev_TYPE *watcher)"
|
1003
|
+
Stops the given watcher again (if active) and clears the pending
|
1004
|
+
status. It is possible that stopped watchers are pending (for example,
|
1005
|
+
non-repeating timers are being stopped when they become pending), but
|
1006
|
+
\&\f(CW\*(C`ev_TYPE_stop\*(C'\fR ensures that the watcher is neither active nor pending. If
|
1007
|
+
you want to free or reuse the memory used by the watcher it is therefore a
|
1008
|
+
good idea to always call its \f(CW\*(C`ev_TYPE_stop\*(C'\fR function.
|
1009
|
+
.IP "bool ev_is_active (ev_TYPE *watcher)" 4
|
1010
|
+
.IX Item "bool ev_is_active (ev_TYPE *watcher)"
|
1011
|
+
Returns a true value iff the watcher is active (i.e. it has been started
|
1012
|
+
and not yet been stopped). As long as a watcher is active you must not modify
|
1013
|
+
it.
|
1014
|
+
.IP "bool ev_is_pending (ev_TYPE *watcher)" 4
|
1015
|
+
.IX Item "bool ev_is_pending (ev_TYPE *watcher)"
|
1016
|
+
Returns a true value iff the watcher is pending, (i.e. it has outstanding
|
1017
|
+
events but its callback has not yet been invoked). As long as a watcher
|
1018
|
+
is pending (but not active) you must not call an init function on it (but
|
1019
|
+
\&\f(CW\*(C`ev_TYPE_set\*(C'\fR is safe), you must not change its priority, and you must
|
1020
|
+
make sure the watcher is available to libev (e.g. you cannot \f(CW\*(C`free ()\*(C'\fR
|
1021
|
+
it).
|
1022
|
+
.IP "callback ev_cb (ev_TYPE *watcher)" 4
|
1023
|
+
.IX Item "callback ev_cb (ev_TYPE *watcher)"
|
1024
|
+
Returns the callback currently set on the watcher.
|
1025
|
+
.IP "ev_cb_set (ev_TYPE *watcher, callback)" 4
|
1026
|
+
.IX Item "ev_cb_set (ev_TYPE *watcher, callback)"
|
1027
|
+
Change the callback. You can change the callback at virtually any time
|
1028
|
+
(modulo threads).
|
1029
|
+
.IP "ev_set_priority (ev_TYPE *watcher, priority)" 4
|
1030
|
+
.IX Item "ev_set_priority (ev_TYPE *watcher, priority)"
|
1031
|
+
.PD 0
|
1032
|
+
.IP "int ev_priority (ev_TYPE *watcher)" 4
|
1033
|
+
.IX Item "int ev_priority (ev_TYPE *watcher)"
|
1034
|
+
.PD
|
1035
|
+
Set and query the priority of the watcher. The priority is a small
|
1036
|
+
integer between \f(CW\*(C`EV_MAXPRI\*(C'\fR (default: \f(CW2\fR) and \f(CW\*(C`EV_MINPRI\*(C'\fR
|
1037
|
+
(default: \f(CW\*(C`\-2\*(C'\fR). Pending watchers with higher priority will be invoked
|
1038
|
+
before watchers with lower priority, but priority will not keep watchers
|
1039
|
+
from being executed (except for \f(CW\*(C`ev_idle\*(C'\fR watchers).
|
1040
|
+
.Sp
|
1041
|
+
This means that priorities are \fIonly\fR used for ordering callback
|
1042
|
+
invocation after new events have been received. This is useful, for
|
1043
|
+
example, to reduce latency after idling, or more often, to bind two
|
1044
|
+
watchers on the same event and make sure one is called first.
|
1045
|
+
.Sp
|
1046
|
+
If you need to suppress invocation when higher priority events are pending
|
1047
|
+
you need to look at \f(CW\*(C`ev_idle\*(C'\fR watchers, which provide this functionality.
|
1048
|
+
.Sp
|
1049
|
+
You \fImust not\fR change the priority of a watcher as long as it is active or
|
1050
|
+
pending.
|
1051
|
+
.Sp
|
1052
|
+
The default priority used by watchers when no priority has been set is
|
1053
|
+
always \f(CW0\fR, which is supposed to not be too high and not be too low :).
|
1054
|
+
.Sp
|
1055
|
+
Setting a priority outside the range of \f(CW\*(C`EV_MINPRI\*(C'\fR to \f(CW\*(C`EV_MAXPRI\*(C'\fR is
|
1056
|
+
fine, as long as you do not mind that the priority value you query might
|
1057
|
+
or might not have been adjusted to be within valid range.
|
1058
|
+
.IP "ev_invoke (loop, ev_TYPE *watcher, int revents)" 4
|
1059
|
+
.IX Item "ev_invoke (loop, ev_TYPE *watcher, int revents)"
|
1060
|
+
Invoke the \f(CW\*(C`watcher\*(C'\fR with the given \f(CW\*(C`loop\*(C'\fR and \f(CW\*(C`revents\*(C'\fR. Neither
|
1061
|
+
\&\f(CW\*(C`loop\*(C'\fR nor \f(CW\*(C`revents\*(C'\fR need to be valid as long as the watcher callback
|
1062
|
+
can deal with that fact.
|
1063
|
+
.IP "int ev_clear_pending (loop, ev_TYPE *watcher)" 4
|
1064
|
+
.IX Item "int ev_clear_pending (loop, ev_TYPE *watcher)"
|
1065
|
+
If the watcher is pending, this function returns clears its pending status
|
1066
|
+
and returns its \f(CW\*(C`revents\*(C'\fR bitset (as if its callback was invoked). If the
|
1067
|
+
watcher isn't pending it does nothing and returns \f(CW0\fR.
|
1068
|
+
.Sh "\s-1ASSOCIATING\s0 \s-1CUSTOM\s0 \s-1DATA\s0 \s-1WITH\s0 A \s-1WATCHER\s0"
|
1069
|
+
.IX Subsection "ASSOCIATING CUSTOM DATA WITH A WATCHER"
|
1070
|
+
Each watcher has, by default, a member \f(CW\*(C`void *data\*(C'\fR that you can change
|
1071
|
+
and read at any time, libev will completely ignore it. This can be used
|
1072
|
+
to associate arbitrary data with your watcher. If you need more data and
|
1073
|
+
don't want to allocate memory and store a pointer to it in that data
|
1074
|
+
member, you can also \*(L"subclass\*(R" the watcher type and provide your own
|
1075
|
+
data:
|
1076
|
+
.PP
|
1077
|
+
.Vb 7
|
1078
|
+
\& struct my_io
|
1079
|
+
\& {
|
1080
|
+
\& struct ev_io io;
|
1081
|
+
\& int otherfd;
|
1082
|
+
\& void *somedata;
|
1083
|
+
\& struct whatever *mostinteresting;
|
1084
|
+
\& }
|
1085
|
+
.Ve
|
1086
|
+
.PP
|
1087
|
+
And since your callback will be called with a pointer to the watcher, you
|
1088
|
+
can cast it back to your own type:
|
1089
|
+
.PP
|
1090
|
+
.Vb 5
|
1091
|
+
\& static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents)
|
1092
|
+
\& {
|
1093
|
+
\& struct my_io *w = (struct my_io *)w_;
|
1094
|
+
\& ...
|
1095
|
+
\& }
|
1096
|
+
.Ve
|
1097
|
+
.PP
|
1098
|
+
More interesting and less C\-conformant ways of casting your callback type
|
1099
|
+
instead have been omitted.
|
1100
|
+
.PP
|
1101
|
+
Another common scenario is having some data structure with multiple
|
1102
|
+
watchers:
|
1103
|
+
.PP
|
1104
|
+
.Vb 6
|
1105
|
+
\& struct my_biggy
|
1106
|
+
\& {
|
1107
|
+
\& int some_data;
|
1108
|
+
\& ev_timer t1;
|
1109
|
+
\& ev_timer t2;
|
1110
|
+
\& }
|
1111
|
+
.Ve
|
1112
|
+
.PP
|
1113
|
+
In this case getting the pointer to \f(CW\*(C`my_biggy\*(C'\fR is a bit more complicated,
|
1114
|
+
you need to use \f(CW\*(C`offsetof\*(C'\fR:
|
1115
|
+
.PP
|
1116
|
+
.Vb 1
|
1117
|
+
\& #include <stddef.h>
|
1118
|
+
\&
|
1119
|
+
\& static void
|
1120
|
+
\& t1_cb (EV_P_ struct ev_timer *w, int revents)
|
1121
|
+
\& {
|
1122
|
+
\& struct my_biggy big = (struct my_biggy *
|
1123
|
+
\& (((char *)w) \- offsetof (struct my_biggy, t1));
|
1124
|
+
\& }
|
1125
|
+
\&
|
1126
|
+
\& static void
|
1127
|
+
\& t2_cb (EV_P_ struct ev_timer *w, int revents)
|
1128
|
+
\& {
|
1129
|
+
\& struct my_biggy big = (struct my_biggy *
|
1130
|
+
\& (((char *)w) \- offsetof (struct my_biggy, t2));
|
1131
|
+
\& }
|
1132
|
+
.Ve
|
1133
|
+
.SH "WATCHER TYPES"
|
1134
|
+
.IX Header "WATCHER TYPES"
|
1135
|
+
This section describes each watcher in detail, but will not repeat
|
1136
|
+
information given in the last section. Any initialisation/set macros,
|
1137
|
+
functions and members specific to the watcher type are explained.
|
1138
|
+
.PP
|
1139
|
+
Members are additionally marked with either \fI[read\-only]\fR, meaning that,
|
1140
|
+
while the watcher is active, you can look at the member and expect some
|
1141
|
+
sensible content, but you must not modify it (you can modify it while the
|
1142
|
+
watcher is stopped to your hearts content), or \fI[read\-write]\fR, which
|
1143
|
+
means you can expect it to have some sensible content while the watcher
|
1144
|
+
is active, but you can also modify it. Modifying it may not do something
|
1145
|
+
sensible or take immediate effect (or do anything at all), but libev will
|
1146
|
+
not crash or malfunction in any way.
|
1147
|
+
.ie n .Sh """ev_io"" \- is this file descriptor readable or writable?"
|
1148
|
+
.el .Sh "\f(CWev_io\fP \- is this file descriptor readable or writable?"
|
1149
|
+
.IX Subsection "ev_io - is this file descriptor readable or writable?"
|
1150
|
+
I/O watchers check whether a file descriptor is readable or writable
|
1151
|
+
in each iteration of the event loop, or, more precisely, when reading
|
1152
|
+
would not block the process and writing would at least be able to write
|
1153
|
+
some data. This behaviour is called level-triggering because you keep
|
1154
|
+
receiving events as long as the condition persists. Remember you can stop
|
1155
|
+
the watcher if you don't want to act on the event and neither want to
|
1156
|
+
receive future events.
|
1157
|
+
.PP
|
1158
|
+
In general you can register as many read and/or write event watchers per
|
1159
|
+
fd as you want (as long as you don't confuse yourself). Setting all file
|
1160
|
+
descriptors to non-blocking mode is also usually a good idea (but not
|
1161
|
+
required if you know what you are doing).
|
1162
|
+
.PP
|
1163
|
+
If you must do this, then force the use of a known-to-be-good backend
|
1164
|
+
(at the time of this writing, this includes only \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR and
|
1165
|
+
\&\f(CW\*(C`EVBACKEND_POLL\*(C'\fR).
|
1166
|
+
.PP
|
1167
|
+
Another thing you have to watch out for is that it is quite easy to
|
1168
|
+
receive \*(L"spurious\*(R" readyness notifications, that is your callback might
|
1169
|
+
be called with \f(CW\*(C`EV_READ\*(C'\fR but a subsequent \f(CW\*(C`read\*(C'\fR(2) will actually block
|
1170
|
+
because there is no data. Not only are some backends known to create a
|
1171
|
+
lot of those (for example solaris ports), it is very easy to get into
|
1172
|
+
this situation even with a relatively standard program structure. Thus
|
1173
|
+
it is best to always use non-blocking I/O: An extra \f(CW\*(C`read\*(C'\fR(2) returning
|
1174
|
+
\&\f(CW\*(C`EAGAIN\*(C'\fR is far preferable to a program hanging until some data arrives.
|
1175
|
+
.PP
|
1176
|
+
If you cannot run the fd in non-blocking mode (for example you should not
|
1177
|
+
play around with an Xlib connection), then you have to seperately re-test
|
1178
|
+
whether a file descriptor is really ready with a known-to-be good interface
|
1179
|
+
such as poll (fortunately in our Xlib example, Xlib already does this on
|
1180
|
+
its own, so its quite safe to use).
|
1181
|
+
.PP
|
1182
|
+
\fIThe special problem of disappearing file descriptors\fR
|
1183
|
+
.IX Subsection "The special problem of disappearing file descriptors"
|
1184
|
+
.PP
|
1185
|
+
Some backends (e.g. kqueue, epoll) need to be told about closing a file
|
1186
|
+
descriptor (either by calling \f(CW\*(C`close\*(C'\fR explicitly or by any other means,
|
1187
|
+
such as \f(CW\*(C`dup\*(C'\fR). The reason is that you register interest in some file
|
1188
|
+
descriptor, but when it goes away, the operating system will silently drop
|
1189
|
+
this interest. If another file descriptor with the same number then is
|
1190
|
+
registered with libev, there is no efficient way to see that this is, in
|
1191
|
+
fact, a different file descriptor.
|
1192
|
+
.PP
|
1193
|
+
To avoid having to explicitly tell libev about such cases, libev follows
|
1194
|
+
the following policy: Each time \f(CW\*(C`ev_io_set\*(C'\fR is being called, libev
|
1195
|
+
will assume that this is potentially a new file descriptor, otherwise
|
1196
|
+
it is assumed that the file descriptor stays the same. That means that
|
1197
|
+
you \fIhave\fR to call \f(CW\*(C`ev_io_set\*(C'\fR (or \f(CW\*(C`ev_io_init\*(C'\fR) when you change the
|
1198
|
+
descriptor even if the file descriptor number itself did not change.
|
1199
|
+
.PP
|
1200
|
+
This is how one would do it normally anyway, the important point is that
|
1201
|
+
the libev application should not optimise around libev but should leave
|
1202
|
+
optimisations to libev.
|
1203
|
+
.PP
|
1204
|
+
\fIThe special problem of dup'ed file descriptors\fR
|
1205
|
+
.IX Subsection "The special problem of dup'ed file descriptors"
|
1206
|
+
.PP
|
1207
|
+
Some backends (e.g. epoll), cannot register events for file descriptors,
|
1208
|
+
but only events for the underlying file descriptions. That means when you
|
1209
|
+
have \f(CW\*(C`dup ()\*(C'\fR'ed file descriptors or weirder constellations, and register
|
1210
|
+
events for them, only one file descriptor might actually receive events.
|
1211
|
+
.PP
|
1212
|
+
There is no workaround possible except not registering events
|
1213
|
+
for potentially \f(CW\*(C`dup ()\*(C'\fR'ed file descriptors, or to resort to
|
1214
|
+
\&\f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or \f(CW\*(C`EVBACKEND_POLL\*(C'\fR.
|
1215
|
+
.PP
|
1216
|
+
\fIThe special problem of fork\fR
|
1217
|
+
.IX Subsection "The special problem of fork"
|
1218
|
+
.PP
|
1219
|
+
Some backends (epoll, kqueue) do not support \f(CW\*(C`fork ()\*(C'\fR at all or exhibit
|
1220
|
+
useless behaviour. Libev fully supports fork, but needs to be told about
|
1221
|
+
it in the child.
|
1222
|
+
.PP
|
1223
|
+
To support fork in your programs, you either have to call
|
1224
|
+
\&\f(CW\*(C`ev_default_fork ()\*(C'\fR or \f(CW\*(C`ev_loop_fork ()\*(C'\fR after a fork in the child,
|
1225
|
+
enable \f(CW\*(C`EVFLAG_FORKCHECK\*(C'\fR, or resort to \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR or
|
1226
|
+
\&\f(CW\*(C`EVBACKEND_POLL\*(C'\fR.
|
1227
|
+
.PP
|
1228
|
+
\fIThe special problem of \s-1SIGPIPE\s0\fR
|
1229
|
+
.IX Subsection "The special problem of SIGPIPE"
|
1230
|
+
.PP
|
1231
|
+
While not really specific to libev, it is easy to forget about \s-1SIGPIPE:\s0
|
1232
|
+
when reading from a pipe whose other end has been closed, your program
|
1233
|
+
gets send a \s-1SIGPIPE\s0, which, by default, aborts your program. For most
|
1234
|
+
programs this is sensible behaviour, for daemons, this is usually
|
1235
|
+
undesirable.
|
1236
|
+
.PP
|
1237
|
+
So when you encounter spurious, unexplained daemon exits, make sure you
|
1238
|
+
ignore \s-1SIGPIPE\s0 (and maybe make sure you log the exit status of your daemon
|
1239
|
+
somewhere, as that would have given you a big clue).
|
1240
|
+
.PP
|
1241
|
+
\fIWatcher-Specific Functions\fR
|
1242
|
+
.IX Subsection "Watcher-Specific Functions"
|
1243
|
+
.IP "ev_io_init (ev_io *, callback, int fd, int events)" 4
|
1244
|
+
.IX Item "ev_io_init (ev_io *, callback, int fd, int events)"
|
1245
|
+
.PD 0
|
1246
|
+
.IP "ev_io_set (ev_io *, int fd, int events)" 4
|
1247
|
+
.IX Item "ev_io_set (ev_io *, int fd, int events)"
|
1248
|
+
.PD
|
1249
|
+
Configures an \f(CW\*(C`ev_io\*(C'\fR watcher. The \f(CW\*(C`fd\*(C'\fR is the file descriptor to
|
1250
|
+
rceeive events for and events is either \f(CW\*(C`EV_READ\*(C'\fR, \f(CW\*(C`EV_WRITE\*(C'\fR or
|
1251
|
+
\&\f(CW\*(C`EV_READ | EV_WRITE\*(C'\fR to receive the given events.
|
1252
|
+
.IP "int fd [read\-only]" 4
|
1253
|
+
.IX Item "int fd [read-only]"
|
1254
|
+
The file descriptor being watched.
|
1255
|
+
.IP "int events [read\-only]" 4
|
1256
|
+
.IX Item "int events [read-only]"
|
1257
|
+
The events being watched.
|
1258
|
+
.PP
|
1259
|
+
\fIExamples\fR
|
1260
|
+
.IX Subsection "Examples"
|
1261
|
+
.PP
|
1262
|
+
Example: Call \f(CW\*(C`stdin_readable_cb\*(C'\fR when \s-1STDIN_FILENO\s0 has become, well
|
1263
|
+
readable, but only once. Since it is likely line-buffered, you could
|
1264
|
+
attempt to read a whole line in the callback.
|
1265
|
+
.PP
|
1266
|
+
.Vb 6
|
1267
|
+
\& static void
|
1268
|
+
\& stdin_readable_cb (struct ev_loop *loop, struct ev_io *w, int revents)
|
1269
|
+
\& {
|
1270
|
+
\& ev_io_stop (loop, w);
|
1271
|
+
\& .. read from stdin here (or from w\->fd) and haqndle any I/O errors
|
1272
|
+
\& }
|
1273
|
+
\&
|
1274
|
+
\& ...
|
1275
|
+
\& struct ev_loop *loop = ev_default_init (0);
|
1276
|
+
\& struct ev_io stdin_readable;
|
1277
|
+
\& ev_io_init (&stdin_readable, stdin_readable_cb, STDIN_FILENO, EV_READ);
|
1278
|
+
\& ev_io_start (loop, &stdin_readable);
|
1279
|
+
\& ev_loop (loop, 0);
|
1280
|
+
.Ve
|
1281
|
+
.ie n .Sh """ev_timer"" \- relative and optionally repeating timeouts"
|
1282
|
+
.el .Sh "\f(CWev_timer\fP \- relative and optionally repeating timeouts"
|
1283
|
+
.IX Subsection "ev_timer - relative and optionally repeating timeouts"
|
1284
|
+
Timer watchers are simple relative timers that generate an event after a
|
1285
|
+
given time, and optionally repeating in regular intervals after that.
|
1286
|
+
.PP
|
1287
|
+
The timers are based on real time, that is, if you register an event that
|
1288
|
+
times out after an hour and you reset your system clock to last years
|
1289
|
+
time, it will still time out after (roughly) and hour. \*(L"Roughly\*(R" because
|
1290
|
+
detecting time jumps is hard, and some inaccuracies are unavoidable (the
|
1291
|
+
monotonic clock option helps a lot here).
|
1292
|
+
.PP
|
1293
|
+
The relative timeouts are calculated relative to the \f(CW\*(C`ev_now ()\*(C'\fR
|
1294
|
+
time. This is usually the right thing as this timestamp refers to the time
|
1295
|
+
of the event triggering whatever timeout you are modifying/starting. If
|
1296
|
+
you suspect event processing to be delayed and you \fIneed\fR to base the timeout
|
1297
|
+
on the current time, use something like this to adjust for this:
|
1298
|
+
.PP
|
1299
|
+
.Vb 1
|
1300
|
+
\& ev_timer_set (&timer, after + ev_now () \- ev_time (), 0.);
|
1301
|
+
.Ve
|
1302
|
+
.PP
|
1303
|
+
The callback is guarenteed to be invoked only when its timeout has passed,
|
1304
|
+
but if multiple timers become ready during the same loop iteration then
|
1305
|
+
order of execution is undefined.
|
1306
|
+
.PP
|
1307
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1308
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1309
|
+
.IP "ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)" 4
|
1310
|
+
.IX Item "ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)"
|
1311
|
+
.PD 0
|
1312
|
+
.IP "ev_timer_set (ev_timer *, ev_tstamp after, ev_tstamp repeat)" 4
|
1313
|
+
.IX Item "ev_timer_set (ev_timer *, ev_tstamp after, ev_tstamp repeat)"
|
1314
|
+
.PD
|
1315
|
+
Configure the timer to trigger after \f(CW\*(C`after\*(C'\fR seconds. If \f(CW\*(C`repeat\*(C'\fR is
|
1316
|
+
\&\f(CW0.\fR, then it will automatically be stopped. If it is positive, then the
|
1317
|
+
timer will automatically be configured to trigger again \f(CW\*(C`repeat\*(C'\fR seconds
|
1318
|
+
later, again, and again, until stopped manually.
|
1319
|
+
.Sp
|
1320
|
+
The timer itself will do a best-effort at avoiding drift, that is, if you
|
1321
|
+
configure a timer to trigger every 10 seconds, then it will trigger at
|
1322
|
+
exactly 10 second intervals. If, however, your program cannot keep up with
|
1323
|
+
the timer (because it takes longer than those 10 seconds to do stuff) the
|
1324
|
+
timer will not fire more than once per event loop iteration.
|
1325
|
+
.IP "ev_timer_again (loop, ev_timer *)" 4
|
1326
|
+
.IX Item "ev_timer_again (loop, ev_timer *)"
|
1327
|
+
This will act as if the timer timed out and restart it again if it is
|
1328
|
+
repeating. The exact semantics are:
|
1329
|
+
.Sp
|
1330
|
+
If the timer is pending, its pending status is cleared.
|
1331
|
+
.Sp
|
1332
|
+
If the timer is started but nonrepeating, stop it (as if it timed out).
|
1333
|
+
.Sp
|
1334
|
+
If the timer is repeating, either start it if necessary (with the
|
1335
|
+
\&\f(CW\*(C`repeat\*(C'\fR value), or reset the running timer to the \f(CW\*(C`repeat\*(C'\fR value.
|
1336
|
+
.Sp
|
1337
|
+
This sounds a bit complicated, but here is a useful and typical
|
1338
|
+
example: Imagine you have a tcp connection and you want a so-called idle
|
1339
|
+
timeout, that is, you want to be called when there have been, say, 60
|
1340
|
+
seconds of inactivity on the socket. The easiest way to do this is to
|
1341
|
+
configure an \f(CW\*(C`ev_timer\*(C'\fR with a \f(CW\*(C`repeat\*(C'\fR value of \f(CW60\fR and then call
|
1342
|
+
\&\f(CW\*(C`ev_timer_again\*(C'\fR each time you successfully read or write some data. If
|
1343
|
+
you go into an idle state where you do not expect data to travel on the
|
1344
|
+
socket, you can \f(CW\*(C`ev_timer_stop\*(C'\fR the timer, and \f(CW\*(C`ev_timer_again\*(C'\fR will
|
1345
|
+
automatically restart it if need be.
|
1346
|
+
.Sp
|
1347
|
+
That means you can ignore the \f(CW\*(C`after\*(C'\fR value and \f(CW\*(C`ev_timer_start\*(C'\fR
|
1348
|
+
altogether and only ever use the \f(CW\*(C`repeat\*(C'\fR value and \f(CW\*(C`ev_timer_again\*(C'\fR:
|
1349
|
+
.Sp
|
1350
|
+
.Vb 8
|
1351
|
+
\& ev_timer_init (timer, callback, 0., 5.);
|
1352
|
+
\& ev_timer_again (loop, timer);
|
1353
|
+
\& ...
|
1354
|
+
\& timer\->again = 17.;
|
1355
|
+
\& ev_timer_again (loop, timer);
|
1356
|
+
\& ...
|
1357
|
+
\& timer\->again = 10.;
|
1358
|
+
\& ev_timer_again (loop, timer);
|
1359
|
+
.Ve
|
1360
|
+
.Sp
|
1361
|
+
This is more slightly efficient then stopping/starting the timer each time
|
1362
|
+
you want to modify its timeout value.
|
1363
|
+
.IP "ev_tstamp repeat [read\-write]" 4
|
1364
|
+
.IX Item "ev_tstamp repeat [read-write]"
|
1365
|
+
The current \f(CW\*(C`repeat\*(C'\fR value. Will be used each time the watcher times out
|
1366
|
+
or \f(CW\*(C`ev_timer_again\*(C'\fR is called and determines the next timeout (if any),
|
1367
|
+
which is also when any modifications are taken into account.
|
1368
|
+
.PP
|
1369
|
+
\fIExamples\fR
|
1370
|
+
.IX Subsection "Examples"
|
1371
|
+
.PP
|
1372
|
+
Example: Create a timer that fires after 60 seconds.
|
1373
|
+
.PP
|
1374
|
+
.Vb 5
|
1375
|
+
\& static void
|
1376
|
+
\& one_minute_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
|
1377
|
+
\& {
|
1378
|
+
\& .. one minute over, w is actually stopped right here
|
1379
|
+
\& }
|
1380
|
+
\&
|
1381
|
+
\& struct ev_timer mytimer;
|
1382
|
+
\& ev_timer_init (&mytimer, one_minute_cb, 60., 0.);
|
1383
|
+
\& ev_timer_start (loop, &mytimer);
|
1384
|
+
.Ve
|
1385
|
+
.PP
|
1386
|
+
Example: Create a timeout timer that times out after 10 seconds of
|
1387
|
+
inactivity.
|
1388
|
+
.PP
|
1389
|
+
.Vb 5
|
1390
|
+
\& static void
|
1391
|
+
\& timeout_cb (struct ev_loop *loop, struct ev_timer *w, int revents)
|
1392
|
+
\& {
|
1393
|
+
\& .. ten seconds without any activity
|
1394
|
+
\& }
|
1395
|
+
\&
|
1396
|
+
\& struct ev_timer mytimer;
|
1397
|
+
\& ev_timer_init (&mytimer, timeout_cb, 0., 10.); /* note, only repeat used */
|
1398
|
+
\& ev_timer_again (&mytimer); /* start timer */
|
1399
|
+
\& ev_loop (loop, 0);
|
1400
|
+
\&
|
1401
|
+
\& // and in some piece of code that gets executed on any "activity":
|
1402
|
+
\& // reset the timeout to start ticking again at 10 seconds
|
1403
|
+
\& ev_timer_again (&mytimer);
|
1404
|
+
.Ve
|
1405
|
+
.ie n .Sh """ev_periodic"" \- to cron or not to cron?"
|
1406
|
+
.el .Sh "\f(CWev_periodic\fP \- to cron or not to cron?"
|
1407
|
+
.IX Subsection "ev_periodic - to cron or not to cron?"
|
1408
|
+
Periodic watchers are also timers of a kind, but they are very versatile
|
1409
|
+
(and unfortunately a bit complex).
|
1410
|
+
.PP
|
1411
|
+
Unlike \f(CW\*(C`ev_timer\*(C'\fR's, they are not based on real time (or relative time)
|
1412
|
+
but on wallclock time (absolute time). You can tell a periodic watcher
|
1413
|
+
to trigger \*(L"at\*(R" some specific point in time. For example, if you tell a
|
1414
|
+
periodic watcher to trigger in 10 seconds (by specifiying e.g. \f(CW\*(C`ev_now ()
|
1415
|
+
+ 10.\*(C'\fR) and then reset your system clock to the last year, then it will
|
1416
|
+
take a year to trigger the event (unlike an \f(CW\*(C`ev_timer\*(C'\fR, which would trigger
|
1417
|
+
roughly 10 seconds later).
|
1418
|
+
.PP
|
1419
|
+
They can also be used to implement vastly more complex timers, such as
|
1420
|
+
triggering an event on each midnight, local time or other, complicated,
|
1421
|
+
rules.
|
1422
|
+
.PP
|
1423
|
+
As with timers, the callback is guarenteed to be invoked only when the
|
1424
|
+
time (\f(CW\*(C`at\*(C'\fR) has been passed, but if multiple periodic timers become ready
|
1425
|
+
during the same loop iteration then order of execution is undefined.
|
1426
|
+
.PP
|
1427
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1428
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1429
|
+
.IP "ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)" 4
|
1430
|
+
.IX Item "ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)"
|
1431
|
+
.PD 0
|
1432
|
+
.IP "ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)" 4
|
1433
|
+
.IX Item "ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)"
|
1434
|
+
.PD
|
1435
|
+
Lots of arguments, lets sort it out... There are basically three modes of
|
1436
|
+
operation, and we will explain them from simplest to complex:
|
1437
|
+
.RS 4
|
1438
|
+
.IP "\(bu" 4
|
1439
|
+
absolute timer (at = time, interval = reschedule_cb = 0)
|
1440
|
+
.Sp
|
1441
|
+
In this configuration the watcher triggers an event at the wallclock time
|
1442
|
+
\&\f(CW\*(C`at\*(C'\fR and doesn't repeat. It will not adjust when a time jump occurs,
|
1443
|
+
that is, if it is to be run at January 1st 2011 then it will run when the
|
1444
|
+
system time reaches or surpasses this time.
|
1445
|
+
.IP "\(bu" 4
|
1446
|
+
repeating interval timer (at = offset, interval > 0, reschedule_cb = 0)
|
1447
|
+
.Sp
|
1448
|
+
In this mode the watcher will always be scheduled to time out at the next
|
1449
|
+
\&\f(CW\*(C`at + N * interval\*(C'\fR time (for some integer N, which can also be negative)
|
1450
|
+
and then repeat, regardless of any time jumps.
|
1451
|
+
.Sp
|
1452
|
+
This can be used to create timers that do not drift with respect to system
|
1453
|
+
time:
|
1454
|
+
.Sp
|
1455
|
+
.Vb 1
|
1456
|
+
\& ev_periodic_set (&periodic, 0., 3600., 0);
|
1457
|
+
.Ve
|
1458
|
+
.Sp
|
1459
|
+
This doesn't mean there will always be 3600 seconds in between triggers,
|
1460
|
+
but only that the the callback will be called when the system time shows a
|
1461
|
+
full hour (\s-1UTC\s0), or more correctly, when the system time is evenly divisible
|
1462
|
+
by 3600.
|
1463
|
+
.Sp
|
1464
|
+
Another way to think about it (for the mathematically inclined) is that
|
1465
|
+
\&\f(CW\*(C`ev_periodic\*(C'\fR will try to run the callback in this mode at the next possible
|
1466
|
+
time where \f(CW\*(C`time = at (mod interval)\*(C'\fR, regardless of any time jumps.
|
1467
|
+
.Sp
|
1468
|
+
For numerical stability it is preferable that the \f(CW\*(C`at\*(C'\fR value is near
|
1469
|
+
\&\f(CW\*(C`ev_now ()\*(C'\fR (the current time), but there is no range requirement for
|
1470
|
+
this value.
|
1471
|
+
.IP "\(bu" 4
|
1472
|
+
manual reschedule mode (at and interval ignored, reschedule_cb = callback)
|
1473
|
+
.Sp
|
1474
|
+
In this mode the values for \f(CW\*(C`interval\*(C'\fR and \f(CW\*(C`at\*(C'\fR are both being
|
1475
|
+
ignored. Instead, each time the periodic watcher gets scheduled, the
|
1476
|
+
reschedule callback will be called with the watcher as first, and the
|
1477
|
+
current time as second argument.
|
1478
|
+
.Sp
|
1479
|
+
\&\s-1NOTE:\s0 \fIThis callback \s-1MUST\s0 \s-1NOT\s0 stop or destroy any periodic watcher,
|
1480
|
+
ever, or make any event loop modifications\fR. If you need to stop it,
|
1481
|
+
return \f(CW\*(C`now + 1e30\*(C'\fR (or so, fudge fudge) and stop it afterwards (e.g. by
|
1482
|
+
starting an \f(CW\*(C`ev_prepare\*(C'\fR watcher, which is legal).
|
1483
|
+
.Sp
|
1484
|
+
Its prototype is \f(CW\*(C`ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
|
1485
|
+
ev_tstamp now)\*(C'\fR, e.g.:
|
1486
|
+
.Sp
|
1487
|
+
.Vb 4
|
1488
|
+
\& static ev_tstamp my_rescheduler (struct ev_periodic *w, ev_tstamp now)
|
1489
|
+
\& {
|
1490
|
+
\& return now + 60.;
|
1491
|
+
\& }
|
1492
|
+
.Ve
|
1493
|
+
.Sp
|
1494
|
+
It must return the next time to trigger, based on the passed time value
|
1495
|
+
(that is, the lowest time value larger than to the second argument). It
|
1496
|
+
will usually be called just before the callback will be triggered, but
|
1497
|
+
might be called at other times, too.
|
1498
|
+
.Sp
|
1499
|
+
\&\s-1NOTE:\s0 \fIThis callback must always return a time that is later than the
|
1500
|
+
passed \f(CI\*(C`now\*(C'\fI value\fR. Not even \f(CW\*(C`now\*(C'\fR itself will do, it \fImust\fR be larger.
|
1501
|
+
.Sp
|
1502
|
+
This can be used to create very complex timers, such as a timer that
|
1503
|
+
triggers on each midnight, local time. To do this, you would calculate the
|
1504
|
+
next midnight after \f(CW\*(C`now\*(C'\fR and return the timestamp value for this. How
|
1505
|
+
you do this is, again, up to you (but it is not trivial, which is the main
|
1506
|
+
reason I omitted it as an example).
|
1507
|
+
.RE
|
1508
|
+
.RS 4
|
1509
|
+
.RE
|
1510
|
+
.IP "ev_periodic_again (loop, ev_periodic *)" 4
|
1511
|
+
.IX Item "ev_periodic_again (loop, ev_periodic *)"
|
1512
|
+
Simply stops and restarts the periodic watcher again. This is only useful
|
1513
|
+
when you changed some parameters or the reschedule callback would return
|
1514
|
+
a different time than the last time it was called (e.g. in a crond like
|
1515
|
+
program when the crontabs have changed).
|
1516
|
+
.IP "ev_tstamp ev_periodic_at (ev_periodic *)" 4
|
1517
|
+
.IX Item "ev_tstamp ev_periodic_at (ev_periodic *)"
|
1518
|
+
When active, returns the absolute time that the watcher is supposed to
|
1519
|
+
trigger next.
|
1520
|
+
.IP "ev_tstamp offset [read\-write]" 4
|
1521
|
+
.IX Item "ev_tstamp offset [read-write]"
|
1522
|
+
When repeating, this contains the offset value, otherwise this is the
|
1523
|
+
absolute point in time (the \f(CW\*(C`at\*(C'\fR value passed to \f(CW\*(C`ev_periodic_set\*(C'\fR).
|
1524
|
+
.Sp
|
1525
|
+
Can be modified any time, but changes only take effect when the periodic
|
1526
|
+
timer fires or \f(CW\*(C`ev_periodic_again\*(C'\fR is being called.
|
1527
|
+
.IP "ev_tstamp interval [read\-write]" 4
|
1528
|
+
.IX Item "ev_tstamp interval [read-write]"
|
1529
|
+
The current interval value. Can be modified any time, but changes only
|
1530
|
+
take effect when the periodic timer fires or \f(CW\*(C`ev_periodic_again\*(C'\fR is being
|
1531
|
+
called.
|
1532
|
+
.IP "ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read\-write]" 4
|
1533
|
+
.IX Item "ev_tstamp (*reschedule_cb)(struct ev_periodic *w, ev_tstamp now) [read-write]"
|
1534
|
+
The current reschedule callback, or \f(CW0\fR, if this functionality is
|
1535
|
+
switched off. Can be changed any time, but changes only take effect when
|
1536
|
+
the periodic timer fires or \f(CW\*(C`ev_periodic_again\*(C'\fR is being called.
|
1537
|
+
.PP
|
1538
|
+
\fIExamples\fR
|
1539
|
+
.IX Subsection "Examples"
|
1540
|
+
.PP
|
1541
|
+
Example: Call a callback every hour, or, more precisely, whenever the
|
1542
|
+
system clock is divisible by 3600. The callback invocation times have
|
1543
|
+
potentially a lot of jittering, but good long-term stability.
|
1544
|
+
.PP
|
1545
|
+
.Vb 5
|
1546
|
+
\& static void
|
1547
|
+
\& clock_cb (struct ev_loop *loop, struct ev_io *w, int revents)
|
1548
|
+
\& {
|
1549
|
+
\& ... its now a full hour (UTC, or TAI or whatever your clock follows)
|
1550
|
+
\& }
|
1551
|
+
\&
|
1552
|
+
\& struct ev_periodic hourly_tick;
|
1553
|
+
\& ev_periodic_init (&hourly_tick, clock_cb, 0., 3600., 0);
|
1554
|
+
\& ev_periodic_start (loop, &hourly_tick);
|
1555
|
+
.Ve
|
1556
|
+
.PP
|
1557
|
+
Example: The same as above, but use a reschedule callback to do it:
|
1558
|
+
.PP
|
1559
|
+
.Vb 1
|
1560
|
+
\& #include <math.h>
|
1561
|
+
\&
|
1562
|
+
\& static ev_tstamp
|
1563
|
+
\& my_scheduler_cb (struct ev_periodic *w, ev_tstamp now)
|
1564
|
+
\& {
|
1565
|
+
\& return fmod (now, 3600.) + 3600.;
|
1566
|
+
\& }
|
1567
|
+
\&
|
1568
|
+
\& ev_periodic_init (&hourly_tick, clock_cb, 0., 0., my_scheduler_cb);
|
1569
|
+
.Ve
|
1570
|
+
.PP
|
1571
|
+
Example: Call a callback every hour, starting now:
|
1572
|
+
.PP
|
1573
|
+
.Vb 4
|
1574
|
+
\& struct ev_periodic hourly_tick;
|
1575
|
+
\& ev_periodic_init (&hourly_tick, clock_cb,
|
1576
|
+
\& fmod (ev_now (loop), 3600.), 3600., 0);
|
1577
|
+
\& ev_periodic_start (loop, &hourly_tick);
|
1578
|
+
.Ve
|
1579
|
+
.ie n .Sh """ev_signal"" \- signal me when a signal gets signalled!"
|
1580
|
+
.el .Sh "\f(CWev_signal\fP \- signal me when a signal gets signalled!"
|
1581
|
+
.IX Subsection "ev_signal - signal me when a signal gets signalled!"
|
1582
|
+
Signal watchers will trigger an event when the process receives a specific
|
1583
|
+
signal one or more times. Even though signals are very asynchronous, libev
|
1584
|
+
will try it's best to deliver signals synchronously, i.e. as part of the
|
1585
|
+
normal event processing, like any other event.
|
1586
|
+
.PP
|
1587
|
+
You can configure as many watchers as you like per signal. Only when the
|
1588
|
+
first watcher gets started will libev actually register a signal watcher
|
1589
|
+
with the kernel (thus it coexists with your own signal handlers as long
|
1590
|
+
as you don't register any with libev). Similarly, when the last signal
|
1591
|
+
watcher for a signal is stopped libev will reset the signal handler to
|
1592
|
+
\&\s-1SIG_DFL\s0 (regardless of what it was set to before).
|
1593
|
+
.PP
|
1594
|
+
If possible and supported, libev will install its handlers with
|
1595
|
+
\&\f(CW\*(C`SA_RESTART\*(C'\fR behaviour enabled, so syscalls should not be unduly
|
1596
|
+
interrupted. If you have a problem with syscalls getting interrupted by
|
1597
|
+
signals you can block all signals in an \f(CW\*(C`ev_check\*(C'\fR watcher and unblock
|
1598
|
+
them in an \f(CW\*(C`ev_prepare\*(C'\fR watcher.
|
1599
|
+
.PP
|
1600
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1601
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1602
|
+
.IP "ev_signal_init (ev_signal *, callback, int signum)" 4
|
1603
|
+
.IX Item "ev_signal_init (ev_signal *, callback, int signum)"
|
1604
|
+
.PD 0
|
1605
|
+
.IP "ev_signal_set (ev_signal *, int signum)" 4
|
1606
|
+
.IX Item "ev_signal_set (ev_signal *, int signum)"
|
1607
|
+
.PD
|
1608
|
+
Configures the watcher to trigger on the given signal number (usually one
|
1609
|
+
of the \f(CW\*(C`SIGxxx\*(C'\fR constants).
|
1610
|
+
.IP "int signum [read\-only]" 4
|
1611
|
+
.IX Item "int signum [read-only]"
|
1612
|
+
The signal the watcher watches out for.
|
1613
|
+
.PP
|
1614
|
+
\fIExamples\fR
|
1615
|
+
.IX Subsection "Examples"
|
1616
|
+
.PP
|
1617
|
+
Example: Try to exit cleanly on \s-1SIGINT\s0 and \s-1SIGTERM\s0.
|
1618
|
+
.PP
|
1619
|
+
.Vb 5
|
1620
|
+
\& static void
|
1621
|
+
\& sigint_cb (struct ev_loop *loop, struct ev_signal *w, int revents)
|
1622
|
+
\& {
|
1623
|
+
\& ev_unloop (loop, EVUNLOOP_ALL);
|
1624
|
+
\& }
|
1625
|
+
\&
|
1626
|
+
\& struct ev_signal signal_watcher;
|
1627
|
+
\& ev_signal_init (&signal_watcher, sigint_cb, SIGINT);
|
1628
|
+
\& ev_signal_start (loop, &sigint_cb);
|
1629
|
+
.Ve
|
1630
|
+
.ie n .Sh """ev_child"" \- watch out for process status changes"
|
1631
|
+
.el .Sh "\f(CWev_child\fP \- watch out for process status changes"
|
1632
|
+
.IX Subsection "ev_child - watch out for process status changes"
|
1633
|
+
Child watchers trigger when your process receives a \s-1SIGCHLD\s0 in response to
|
1634
|
+
some child status changes (most typically when a child of yours dies). It
|
1635
|
+
is permissible to install a child watcher \fIafter\fR the child has been
|
1636
|
+
forked (which implies it might have already exited), as long as the event
|
1637
|
+
loop isn't entered (or is continued from a watcher).
|
1638
|
+
.PP
|
1639
|
+
Only the default event loop is capable of handling signals, and therefore
|
1640
|
+
you can only rgeister child watchers in the default event loop.
|
1641
|
+
.PP
|
1642
|
+
\fIProcess Interaction\fR
|
1643
|
+
.IX Subsection "Process Interaction"
|
1644
|
+
.PP
|
1645
|
+
Libev grabs \f(CW\*(C`SIGCHLD\*(C'\fR as soon as the default event loop is
|
1646
|
+
initialised. This is necessary to guarantee proper behaviour even if
|
1647
|
+
the first child watcher is started after the child exits. The occurance
|
1648
|
+
of \f(CW\*(C`SIGCHLD\*(C'\fR is recorded asynchronously, but child reaping is done
|
1649
|
+
synchronously as part of the event loop processing. Libev always reaps all
|
1650
|
+
children, even ones not watched.
|
1651
|
+
.PP
|
1652
|
+
\fIOverriding the Built-In Processing\fR
|
1653
|
+
.IX Subsection "Overriding the Built-In Processing"
|
1654
|
+
.PP
|
1655
|
+
Libev offers no special support for overriding the built-in child
|
1656
|
+
processing, but if your application collides with libev's default child
|
1657
|
+
handler, you can override it easily by installing your own handler for
|
1658
|
+
\&\f(CW\*(C`SIGCHLD\*(C'\fR after initialising the default loop, and making sure the
|
1659
|
+
default loop never gets destroyed. You are encouraged, however, to use an
|
1660
|
+
event-based approach to child reaping and thus use libev's support for
|
1661
|
+
that, so other libev users can use \f(CW\*(C`ev_child\*(C'\fR watchers freely.
|
1662
|
+
.PP
|
1663
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1664
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1665
|
+
.IP "ev_child_init (ev_child *, callback, int pid, int trace)" 4
|
1666
|
+
.IX Item "ev_child_init (ev_child *, callback, int pid, int trace)"
|
1667
|
+
.PD 0
|
1668
|
+
.IP "ev_child_set (ev_child *, int pid, int trace)" 4
|
1669
|
+
.IX Item "ev_child_set (ev_child *, int pid, int trace)"
|
1670
|
+
.PD
|
1671
|
+
Configures the watcher to wait for status changes of process \f(CW\*(C`pid\*(C'\fR (or
|
1672
|
+
\&\fIany\fR process if \f(CW\*(C`pid\*(C'\fR is specified as \f(CW0\fR). The callback can look
|
1673
|
+
at the \f(CW\*(C`rstatus\*(C'\fR member of the \f(CW\*(C`ev_child\*(C'\fR watcher structure to see
|
1674
|
+
the status word (use the macros from \f(CW\*(C`sys/wait.h\*(C'\fR and see your systems
|
1675
|
+
\&\f(CW\*(C`waitpid\*(C'\fR documentation). The \f(CW\*(C`rpid\*(C'\fR member contains the pid of the
|
1676
|
+
process causing the status change. \f(CW\*(C`trace\*(C'\fR must be either \f(CW0\fR (only
|
1677
|
+
activate the watcher when the process terminates) or \f(CW1\fR (additionally
|
1678
|
+
activate the watcher when the process is stopped or continued).
|
1679
|
+
.IP "int pid [read\-only]" 4
|
1680
|
+
.IX Item "int pid [read-only]"
|
1681
|
+
The process id this watcher watches out for, or \f(CW0\fR, meaning any process id.
|
1682
|
+
.IP "int rpid [read\-write]" 4
|
1683
|
+
.IX Item "int rpid [read-write]"
|
1684
|
+
The process id that detected a status change.
|
1685
|
+
.IP "int rstatus [read\-write]" 4
|
1686
|
+
.IX Item "int rstatus [read-write]"
|
1687
|
+
The process exit/trace status caused by \f(CW\*(C`rpid\*(C'\fR (see your systems
|
1688
|
+
\&\f(CW\*(C`waitpid\*(C'\fR and \f(CW\*(C`sys/wait.h\*(C'\fR documentation for details).
|
1689
|
+
.PP
|
1690
|
+
\fIExamples\fR
|
1691
|
+
.IX Subsection "Examples"
|
1692
|
+
.PP
|
1693
|
+
Example: \f(CW\*(C`fork()\*(C'\fR a new process and install a child handler to wait for
|
1694
|
+
its completion.
|
1695
|
+
.PP
|
1696
|
+
.Vb 1
|
1697
|
+
\& ev_child cw;
|
1698
|
+
\&
|
1699
|
+
\& static void
|
1700
|
+
\& child_cb (EV_P_ struct ev_child *w, int revents)
|
1701
|
+
\& {
|
1702
|
+
\& ev_child_stop (EV_A_ w);
|
1703
|
+
\& printf ("process %d exited with status %x\en", w\->rpid, w\->rstatus);
|
1704
|
+
\& }
|
1705
|
+
\&
|
1706
|
+
\& pid_t pid = fork ();
|
1707
|
+
\&
|
1708
|
+
\& if (pid < 0)
|
1709
|
+
\& // error
|
1710
|
+
\& else if (pid == 0)
|
1711
|
+
\& {
|
1712
|
+
\& // the forked child executes here
|
1713
|
+
\& exit (1);
|
1714
|
+
\& }
|
1715
|
+
\& else
|
1716
|
+
\& {
|
1717
|
+
\& ev_child_init (&cw, child_cb, pid, 0);
|
1718
|
+
\& ev_child_start (EV_DEFAULT_ &cw);
|
1719
|
+
\& }
|
1720
|
+
.Ve
|
1721
|
+
.ie n .Sh """ev_stat"" \- did the file attributes just change?"
|
1722
|
+
.el .Sh "\f(CWev_stat\fP \- did the file attributes just change?"
|
1723
|
+
.IX Subsection "ev_stat - did the file attributes just change?"
|
1724
|
+
This watches a filesystem path for attribute changes. That is, it calls
|
1725
|
+
\&\f(CW\*(C`stat\*(C'\fR regularly (or when the \s-1OS\s0 says it changed) and sees if it changed
|
1726
|
+
compared to the last time, invoking the callback if it did.
|
1727
|
+
.PP
|
1728
|
+
The path does not need to exist: changing from \*(L"path exists\*(R" to \*(L"path does
|
1729
|
+
not exist\*(R" is a status change like any other. The condition \*(L"path does
|
1730
|
+
not exist\*(R" is signified by the \f(CW\*(C`st_nlink\*(C'\fR field being zero (which is
|
1731
|
+
otherwise always forced to be at least one) and all the other fields of
|
1732
|
+
the stat buffer having unspecified contents.
|
1733
|
+
.PP
|
1734
|
+
The path \fIshould\fR be absolute and \fImust not\fR end in a slash. If it is
|
1735
|
+
relative and your working directory changes, the behaviour is undefined.
|
1736
|
+
.PP
|
1737
|
+
Since there is no standard to do this, the portable implementation simply
|
1738
|
+
calls \f(CW\*(C`stat (2)\*(C'\fR regularly on the path to see if it changed somehow. You
|
1739
|
+
can specify a recommended polling interval for this case. If you specify
|
1740
|
+
a polling interval of \f(CW0\fR (highly recommended!) then a \fIsuitable,
|
1741
|
+
unspecified default\fR value will be used (which you can expect to be around
|
1742
|
+
five seconds, although this might change dynamically). Libev will also
|
1743
|
+
impose a minimum interval which is currently around \f(CW0.1\fR, but thats
|
1744
|
+
usually overkill.
|
1745
|
+
.PP
|
1746
|
+
This watcher type is not meant for massive numbers of stat watchers,
|
1747
|
+
as even with OS-supported change notifications, this can be
|
1748
|
+
resource-intensive.
|
1749
|
+
.PP
|
1750
|
+
At the time of this writing, only the Linux inotify interface is
|
1751
|
+
implemented (implementing kqueue support is left as an exercise for the
|
1752
|
+
reader, note, however, that the author sees no way of implementing ev_stat
|
1753
|
+
semantics with kqueue). Inotify will be used to give hints only and should
|
1754
|
+
not change the semantics of \f(CW\*(C`ev_stat\*(C'\fR watchers, which means that libev
|
1755
|
+
sometimes needs to fall back to regular polling again even with inotify,
|
1756
|
+
but changes are usually detected immediately, and if the file exists there
|
1757
|
+
will be no polling.
|
1758
|
+
.PP
|
1759
|
+
\fI\s-1ABI\s0 Issues (Largefile Support)\fR
|
1760
|
+
.IX Subsection "ABI Issues (Largefile Support)"
|
1761
|
+
.PP
|
1762
|
+
Libev by default (unless the user overrides this) uses the default
|
1763
|
+
compilation environment, which means that on systems with optionally
|
1764
|
+
disabled large file support, you get the 32 bit version of the stat
|
1765
|
+
structure. When using the library from programs that change the \s-1ABI\s0 to
|
1766
|
+
use 64 bit file offsets the programs will fail. In that case you have to
|
1767
|
+
compile libev with the same flags to get binary compatibility. This is
|
1768
|
+
obviously the case with any flags that change the \s-1ABI\s0, but the problem is
|
1769
|
+
most noticably with ev_stat and largefile support.
|
1770
|
+
.PP
|
1771
|
+
\fIInotify\fR
|
1772
|
+
.IX Subsection "Inotify"
|
1773
|
+
.PP
|
1774
|
+
When \f(CW\*(C`inotify (7)\*(C'\fR support has been compiled into libev (generally only
|
1775
|
+
available on Linux) and present at runtime, it will be used to speed up
|
1776
|
+
change detection where possible. The inotify descriptor will be created lazily
|
1777
|
+
when the first \f(CW\*(C`ev_stat\*(C'\fR watcher is being started.
|
1778
|
+
.PP
|
1779
|
+
Inotify presence does not change the semantics of \f(CW\*(C`ev_stat\*(C'\fR watchers
|
1780
|
+
except that changes might be detected earlier, and in some cases, to avoid
|
1781
|
+
making regular \f(CW\*(C`stat\*(C'\fR calls. Even in the presence of inotify support
|
1782
|
+
there are many cases where libev has to resort to regular \f(CW\*(C`stat\*(C'\fR polling.
|
1783
|
+
.PP
|
1784
|
+
(There is no support for kqueue, as apparently it cannot be used to
|
1785
|
+
implement this functionality, due to the requirement of having a file
|
1786
|
+
descriptor open on the object at all times).
|
1787
|
+
.PP
|
1788
|
+
\fIThe special problem of stat time resolution\fR
|
1789
|
+
.IX Subsection "The special problem of stat time resolution"
|
1790
|
+
.PP
|
1791
|
+
The \f(CW\*(C`stat ()\*(C'\fR syscall only supports full-second resolution portably, and
|
1792
|
+
even on systems where the resolution is higher, many filesystems still
|
1793
|
+
only support whole seconds.
|
1794
|
+
.PP
|
1795
|
+
That means that, if the time is the only thing that changes, you can
|
1796
|
+
easily miss updates: on the first update, \f(CW\*(C`ev_stat\*(C'\fR detects a change and
|
1797
|
+
calls your callback, which does something. When there is another update
|
1798
|
+
within the same second, \f(CW\*(C`ev_stat\*(C'\fR will be unable to detect it as the stat
|
1799
|
+
data does not change.
|
1800
|
+
.PP
|
1801
|
+
The solution to this is to delay acting on a change for slightly more
|
1802
|
+
than second (or till slightly after the next full second boundary), using
|
1803
|
+
a roughly one-second-delay \f(CW\*(C`ev_timer\*(C'\fR (e.g. \f(CW\*(C`ev_timer_set (w, 0., 1.02);
|
1804
|
+
ev_timer_again (loop, w)\*(C'\fR).
|
1805
|
+
.PP
|
1806
|
+
The \f(CW.02\fR offset is added to work around small timing inconsistencies
|
1807
|
+
of some operating systems (where the second counter of the current time
|
1808
|
+
might be be delayed. One such system is the Linux kernel, where a call to
|
1809
|
+
\&\f(CW\*(C`gettimeofday\*(C'\fR might return a timestamp with a full second later than
|
1810
|
+
a subsequent \f(CW\*(C`time\*(C'\fR call \- if the equivalent of \f(CW\*(C`time ()\*(C'\fR is used to
|
1811
|
+
update file times then there will be a small window where the kernel uses
|
1812
|
+
the previous second to update file times but libev might already execute
|
1813
|
+
the timer callback).
|
1814
|
+
.PP
|
1815
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1816
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1817
|
+
.IP "ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)" 4
|
1818
|
+
.IX Item "ev_stat_init (ev_stat *, callback, const char *path, ev_tstamp interval)"
|
1819
|
+
.PD 0
|
1820
|
+
.IP "ev_stat_set (ev_stat *, const char *path, ev_tstamp interval)" 4
|
1821
|
+
.IX Item "ev_stat_set (ev_stat *, const char *path, ev_tstamp interval)"
|
1822
|
+
.PD
|
1823
|
+
Configures the watcher to wait for status changes of the given
|
1824
|
+
\&\f(CW\*(C`path\*(C'\fR. The \f(CW\*(C`interval\*(C'\fR is a hint on how quickly a change is expected to
|
1825
|
+
be detected and should normally be specified as \f(CW0\fR to let libev choose
|
1826
|
+
a suitable value. The memory pointed to by \f(CW\*(C`path\*(C'\fR must point to the same
|
1827
|
+
path for as long as the watcher is active.
|
1828
|
+
.Sp
|
1829
|
+
The callback will receive \f(CW\*(C`EV_STAT\*(C'\fR when a change was detected, relative
|
1830
|
+
to the attributes at the time the watcher was started (or the last change
|
1831
|
+
was detected).
|
1832
|
+
.IP "ev_stat_stat (loop, ev_stat *)" 4
|
1833
|
+
.IX Item "ev_stat_stat (loop, ev_stat *)"
|
1834
|
+
Updates the stat buffer immediately with new values. If you change the
|
1835
|
+
watched path in your callback, you could call this function to avoid
|
1836
|
+
detecting this change (while introducing a race condition if you are not
|
1837
|
+
the only one changing the path). Can also be useful simply to find out the
|
1838
|
+
new values.
|
1839
|
+
.IP "ev_statdata attr [read\-only]" 4
|
1840
|
+
.IX Item "ev_statdata attr [read-only]"
|
1841
|
+
The most-recently detected attributes of the file. Although the type is
|
1842
|
+
\&\f(CW\*(C`ev_statdata\*(C'\fR, this is usually the (or one of the) \f(CW\*(C`struct stat\*(C'\fR types
|
1843
|
+
suitable for your system, but you can only rely on the POSIX-standardised
|
1844
|
+
members to be present. If the \f(CW\*(C`st_nlink\*(C'\fR member is \f(CW0\fR, then there was
|
1845
|
+
some error while \f(CW\*(C`stat\*(C'\fRing the file.
|
1846
|
+
.IP "ev_statdata prev [read\-only]" 4
|
1847
|
+
.IX Item "ev_statdata prev [read-only]"
|
1848
|
+
The previous attributes of the file. The callback gets invoked whenever
|
1849
|
+
\&\f(CW\*(C`prev\*(C'\fR != \f(CW\*(C`attr\*(C'\fR, or, more precisely, one or more of these members
|
1850
|
+
differ: \f(CW\*(C`st_dev\*(C'\fR, \f(CW\*(C`st_ino\*(C'\fR, \f(CW\*(C`st_mode\*(C'\fR, \f(CW\*(C`st_nlink\*(C'\fR, \f(CW\*(C`st_uid\*(C'\fR,
|
1851
|
+
\&\f(CW\*(C`st_gid\*(C'\fR, \f(CW\*(C`st_rdev\*(C'\fR, \f(CW\*(C`st_size\*(C'\fR, \f(CW\*(C`st_atime\*(C'\fR, \f(CW\*(C`st_mtime\*(C'\fR, \f(CW\*(C`st_ctime\*(C'\fR.
|
1852
|
+
.IP "ev_tstamp interval [read\-only]" 4
|
1853
|
+
.IX Item "ev_tstamp interval [read-only]"
|
1854
|
+
The specified interval.
|
1855
|
+
.IP "const char *path [read\-only]" 4
|
1856
|
+
.IX Item "const char *path [read-only]"
|
1857
|
+
The filesystem path that is being watched.
|
1858
|
+
.PP
|
1859
|
+
\fIExamples\fR
|
1860
|
+
.IX Subsection "Examples"
|
1861
|
+
.PP
|
1862
|
+
Example: Watch \f(CW\*(C`/etc/passwd\*(C'\fR for attribute changes.
|
1863
|
+
.PP
|
1864
|
+
.Vb 10
|
1865
|
+
\& static void
|
1866
|
+
\& passwd_cb (struct ev_loop *loop, ev_stat *w, int revents)
|
1867
|
+
\& {
|
1868
|
+
\& /* /etc/passwd changed in some way */
|
1869
|
+
\& if (w\->attr.st_nlink)
|
1870
|
+
\& {
|
1871
|
+
\& printf ("passwd current size %ld\en", (long)w\->attr.st_size);
|
1872
|
+
\& printf ("passwd current atime %ld\en", (long)w\->attr.st_mtime);
|
1873
|
+
\& printf ("passwd current mtime %ld\en", (long)w\->attr.st_mtime);
|
1874
|
+
\& }
|
1875
|
+
\& else
|
1876
|
+
\& /* you shalt not abuse printf for puts */
|
1877
|
+
\& puts ("wow, /etc/passwd is not there, expect problems. "
|
1878
|
+
\& "if this is windows, they already arrived\en");
|
1879
|
+
\& }
|
1880
|
+
\&
|
1881
|
+
\& ...
|
1882
|
+
\& ev_stat passwd;
|
1883
|
+
\&
|
1884
|
+
\& ev_stat_init (&passwd, passwd_cb, "/etc/passwd", 0.);
|
1885
|
+
\& ev_stat_start (loop, &passwd);
|
1886
|
+
.Ve
|
1887
|
+
.PP
|
1888
|
+
Example: Like above, but additionally use a one-second delay so we do not
|
1889
|
+
miss updates (however, frequent updates will delay processing, too, so
|
1890
|
+
one might do the work both on \f(CW\*(C`ev_stat\*(C'\fR callback invocation \fIand\fR on
|
1891
|
+
\&\f(CW\*(C`ev_timer\*(C'\fR callback invocation).
|
1892
|
+
.PP
|
1893
|
+
.Vb 2
|
1894
|
+
\& static ev_stat passwd;
|
1895
|
+
\& static ev_timer timer;
|
1896
|
+
\&
|
1897
|
+
\& static void
|
1898
|
+
\& timer_cb (EV_P_ ev_timer *w, int revents)
|
1899
|
+
\& {
|
1900
|
+
\& ev_timer_stop (EV_A_ w);
|
1901
|
+
\&
|
1902
|
+
\& /* now it\*(Aqs one second after the most recent passwd change */
|
1903
|
+
\& }
|
1904
|
+
\&
|
1905
|
+
\& static void
|
1906
|
+
\& stat_cb (EV_P_ ev_stat *w, int revents)
|
1907
|
+
\& {
|
1908
|
+
\& /* reset the one\-second timer */
|
1909
|
+
\& ev_timer_again (EV_A_ &timer);
|
1910
|
+
\& }
|
1911
|
+
\&
|
1912
|
+
\& ...
|
1913
|
+
\& ev_stat_init (&passwd, stat_cb, "/etc/passwd", 0.);
|
1914
|
+
\& ev_stat_start (loop, &passwd);
|
1915
|
+
\& ev_timer_init (&timer, timer_cb, 0., 1.02);
|
1916
|
+
.Ve
|
1917
|
+
.ie n .Sh """ev_idle"" \- when you've got nothing better to do..."
|
1918
|
+
.el .Sh "\f(CWev_idle\fP \- when you've got nothing better to do..."
|
1919
|
+
.IX Subsection "ev_idle - when you've got nothing better to do..."
|
1920
|
+
Idle watchers trigger events when no other events of the same or higher
|
1921
|
+
priority are pending (prepare, check and other idle watchers do not
|
1922
|
+
count).
|
1923
|
+
.PP
|
1924
|
+
That is, as long as your process is busy handling sockets or timeouts
|
1925
|
+
(or even signals, imagine) of the same or higher priority it will not be
|
1926
|
+
triggered. But when your process is idle (or only lower-priority watchers
|
1927
|
+
are pending), the idle watchers are being called once per event loop
|
1928
|
+
iteration \- until stopped, that is, or your process receives more events
|
1929
|
+
and becomes busy again with higher priority stuff.
|
1930
|
+
.PP
|
1931
|
+
The most noteworthy effect is that as long as any idle watchers are
|
1932
|
+
active, the process will not block when waiting for new events.
|
1933
|
+
.PP
|
1934
|
+
Apart from keeping your process non-blocking (which is a useful
|
1935
|
+
effect on its own sometimes), idle watchers are a good place to do
|
1936
|
+
\&\*(L"pseudo-background processing\*(R", or delay processing stuff to after the
|
1937
|
+
event loop has handled all outstanding events.
|
1938
|
+
.PP
|
1939
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
1940
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
1941
|
+
.IP "ev_idle_init (ev_signal *, callback)" 4
|
1942
|
+
.IX Item "ev_idle_init (ev_signal *, callback)"
|
1943
|
+
Initialises and configures the idle watcher \- it has no parameters of any
|
1944
|
+
kind. There is a \f(CW\*(C`ev_idle_set\*(C'\fR macro, but using it is utterly pointless,
|
1945
|
+
believe me.
|
1946
|
+
.PP
|
1947
|
+
\fIExamples\fR
|
1948
|
+
.IX Subsection "Examples"
|
1949
|
+
.PP
|
1950
|
+
Example: Dynamically allocate an \f(CW\*(C`ev_idle\*(C'\fR watcher, start it, and in the
|
1951
|
+
callback, free it. Also, use no error checking, as usual.
|
1952
|
+
.PP
|
1953
|
+
.Vb 7
|
1954
|
+
\& static void
|
1955
|
+
\& idle_cb (struct ev_loop *loop, struct ev_idle *w, int revents)
|
1956
|
+
\& {
|
1957
|
+
\& free (w);
|
1958
|
+
\& // now do something you wanted to do when the program has
|
1959
|
+
\& // no longer anything immediate to do.
|
1960
|
+
\& }
|
1961
|
+
\&
|
1962
|
+
\& struct ev_idle *idle_watcher = malloc (sizeof (struct ev_idle));
|
1963
|
+
\& ev_idle_init (idle_watcher, idle_cb);
|
1964
|
+
\& ev_idle_start (loop, idle_cb);
|
1965
|
+
.Ve
|
1966
|
+
.ie n .Sh """ev_prepare""\fP and \f(CW""ev_check"" \- customise your event loop!"
|
1967
|
+
.el .Sh "\f(CWev_prepare\fP and \f(CWev_check\fP \- customise your event loop!"
|
1968
|
+
.IX Subsection "ev_prepare and ev_check - customise your event loop!"
|
1969
|
+
Prepare and check watchers are usually (but not always) used in tandem:
|
1970
|
+
prepare watchers get invoked before the process blocks and check watchers
|
1971
|
+
afterwards.
|
1972
|
+
.PP
|
1973
|
+
You \fImust not\fR call \f(CW\*(C`ev_loop\*(C'\fR or similar functions that enter
|
1974
|
+
the current event loop from either \f(CW\*(C`ev_prepare\*(C'\fR or \f(CW\*(C`ev_check\*(C'\fR
|
1975
|
+
watchers. Other loops than the current one are fine, however. The
|
1976
|
+
rationale behind this is that you do not need to check for recursion in
|
1977
|
+
those watchers, i.e. the sequence will always be \f(CW\*(C`ev_prepare\*(C'\fR, blocking,
|
1978
|
+
\&\f(CW\*(C`ev_check\*(C'\fR so if you have one watcher of each kind they will always be
|
1979
|
+
called in pairs bracketing the blocking call.
|
1980
|
+
.PP
|
1981
|
+
Their main purpose is to integrate other event mechanisms into libev and
|
1982
|
+
their use is somewhat advanced. This could be used, for example, to track
|
1983
|
+
variable changes, implement your own watchers, integrate net-snmp or a
|
1984
|
+
coroutine library and lots more. They are also occasionally useful if
|
1985
|
+
you cache some data and want to flush it before blocking (for example,
|
1986
|
+
in X programs you might want to do an \f(CW\*(C`XFlush ()\*(C'\fR in an \f(CW\*(C`ev_prepare\*(C'\fR
|
1987
|
+
watcher).
|
1988
|
+
.PP
|
1989
|
+
This is done by examining in each prepare call which file descriptors need
|
1990
|
+
to be watched by the other library, registering \f(CW\*(C`ev_io\*(C'\fR watchers for
|
1991
|
+
them and starting an \f(CW\*(C`ev_timer\*(C'\fR watcher for any timeouts (many libraries
|
1992
|
+
provide just this functionality). Then, in the check watcher you check for
|
1993
|
+
any events that occured (by checking the pending status of all watchers
|
1994
|
+
and stopping them) and call back into the library. The I/O and timer
|
1995
|
+
callbacks will never actually be called (but must be valid nevertheless,
|
1996
|
+
because you never know, you know?).
|
1997
|
+
.PP
|
1998
|
+
As another example, the Perl Coro module uses these hooks to integrate
|
1999
|
+
coroutines into libev programs, by yielding to other active coroutines
|
2000
|
+
during each prepare and only letting the process block if no coroutines
|
2001
|
+
are ready to run (it's actually more complicated: it only runs coroutines
|
2002
|
+
with priority higher than or equal to the event loop and one coroutine
|
2003
|
+
of lower priority, but only once, using idle watchers to keep the event
|
2004
|
+
loop from blocking if lower-priority coroutines are active, thus mapping
|
2005
|
+
low-priority coroutines to idle/background tasks).
|
2006
|
+
.PP
|
2007
|
+
It is recommended to give \f(CW\*(C`ev_check\*(C'\fR watchers highest (\f(CW\*(C`EV_MAXPRI\*(C'\fR)
|
2008
|
+
priority, to ensure that they are being run before any other watchers
|
2009
|
+
after the poll. Also, \f(CW\*(C`ev_check\*(C'\fR watchers (and \f(CW\*(C`ev_prepare\*(C'\fR watchers,
|
2010
|
+
too) should not activate (\*(L"feed\*(R") events into libev. While libev fully
|
2011
|
+
supports this, they might get executed before other \f(CW\*(C`ev_check\*(C'\fR watchers
|
2012
|
+
did their job. As \f(CW\*(C`ev_check\*(C'\fR watchers are often used to embed other
|
2013
|
+
(non-libev) event loops those other event loops might be in an unusable
|
2014
|
+
state until their \f(CW\*(C`ev_check\*(C'\fR watcher ran (always remind yourself to
|
2015
|
+
coexist peacefully with others).
|
2016
|
+
.PP
|
2017
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
2018
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
2019
|
+
.IP "ev_prepare_init (ev_prepare *, callback)" 4
|
2020
|
+
.IX Item "ev_prepare_init (ev_prepare *, callback)"
|
2021
|
+
.PD 0
|
2022
|
+
.IP "ev_check_init (ev_check *, callback)" 4
|
2023
|
+
.IX Item "ev_check_init (ev_check *, callback)"
|
2024
|
+
.PD
|
2025
|
+
Initialises and configures the prepare or check watcher \- they have no
|
2026
|
+
parameters of any kind. There are \f(CW\*(C`ev_prepare_set\*(C'\fR and \f(CW\*(C`ev_check_set\*(C'\fR
|
2027
|
+
macros, but using them is utterly, utterly and completely pointless.
|
2028
|
+
.PP
|
2029
|
+
\fIExamples\fR
|
2030
|
+
.IX Subsection "Examples"
|
2031
|
+
.PP
|
2032
|
+
There are a number of principal ways to embed other event loops or modules
|
2033
|
+
into libev. Here are some ideas on how to include libadns into libev
|
2034
|
+
(there is a Perl module named \f(CW\*(C`EV::ADNS\*(C'\fR that does this, which you could
|
2035
|
+
use as a working example. Another Perl module named \f(CW\*(C`EV::Glib\*(C'\fR embeds a
|
2036
|
+
Glib main context into libev, and finally, \f(CW\*(C`Glib::EV\*(C'\fR embeds \s-1EV\s0 into the
|
2037
|
+
Glib event loop).
|
2038
|
+
.PP
|
2039
|
+
Method 1: Add \s-1IO\s0 watchers and a timeout watcher in a prepare handler,
|
2040
|
+
and in a check watcher, destroy them and call into libadns. What follows
|
2041
|
+
is pseudo-code only of course. This requires you to either use a low
|
2042
|
+
priority for the check watcher or use \f(CW\*(C`ev_clear_pending\*(C'\fR explicitly, as
|
2043
|
+
the callbacks for the IO/timeout watchers might not have been called yet.
|
2044
|
+
.PP
|
2045
|
+
.Vb 2
|
2046
|
+
\& static ev_io iow [nfd];
|
2047
|
+
\& static ev_timer tw;
|
2048
|
+
\&
|
2049
|
+
\& static void
|
2050
|
+
\& io_cb (ev_loop *loop, ev_io *w, int revents)
|
2051
|
+
\& {
|
2052
|
+
\& }
|
2053
|
+
\&
|
2054
|
+
\& // create io watchers for each fd and a timer before blocking
|
2055
|
+
\& static void
|
2056
|
+
\& adns_prepare_cb (ev_loop *loop, ev_prepare *w, int revents)
|
2057
|
+
\& {
|
2058
|
+
\& int timeout = 3600000;
|
2059
|
+
\& struct pollfd fds [nfd];
|
2060
|
+
\& // actual code will need to loop here and realloc etc.
|
2061
|
+
\& adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ()));
|
2062
|
+
\&
|
2063
|
+
\& /* the callback is illegal, but won\*(Aqt be called as we stop during check */
|
2064
|
+
\& ev_timer_init (&tw, 0, timeout * 1e\-3);
|
2065
|
+
\& ev_timer_start (loop, &tw);
|
2066
|
+
\&
|
2067
|
+
\& // create one ev_io per pollfd
|
2068
|
+
\& for (int i = 0; i < nfd; ++i)
|
2069
|
+
\& {
|
2070
|
+
\& ev_io_init (iow + i, io_cb, fds [i].fd,
|
2071
|
+
\& ((fds [i].events & POLLIN ? EV_READ : 0)
|
2072
|
+
\& | (fds [i].events & POLLOUT ? EV_WRITE : 0)));
|
2073
|
+
\&
|
2074
|
+
\& fds [i].revents = 0;
|
2075
|
+
\& ev_io_start (loop, iow + i);
|
2076
|
+
\& }
|
2077
|
+
\& }
|
2078
|
+
\&
|
2079
|
+
\& // stop all watchers after blocking
|
2080
|
+
\& static void
|
2081
|
+
\& adns_check_cb (ev_loop *loop, ev_check *w, int revents)
|
2082
|
+
\& {
|
2083
|
+
\& ev_timer_stop (loop, &tw);
|
2084
|
+
\&
|
2085
|
+
\& for (int i = 0; i < nfd; ++i)
|
2086
|
+
\& {
|
2087
|
+
\& // set the relevant poll flags
|
2088
|
+
\& // could also call adns_processreadable etc. here
|
2089
|
+
\& struct pollfd *fd = fds + i;
|
2090
|
+
\& int revents = ev_clear_pending (iow + i);
|
2091
|
+
\& if (revents & EV_READ ) fd\->revents |= fd\->events & POLLIN;
|
2092
|
+
\& if (revents & EV_WRITE) fd\->revents |= fd\->events & POLLOUT;
|
2093
|
+
\&
|
2094
|
+
\& // now stop the watcher
|
2095
|
+
\& ev_io_stop (loop, iow + i);
|
2096
|
+
\& }
|
2097
|
+
\&
|
2098
|
+
\& adns_afterpoll (adns, fds, nfd, timeval_from (ev_now (loop));
|
2099
|
+
\& }
|
2100
|
+
.Ve
|
2101
|
+
.PP
|
2102
|
+
Method 2: This would be just like method 1, but you run \f(CW\*(C`adns_afterpoll\*(C'\fR
|
2103
|
+
in the prepare watcher and would dispose of the check watcher.
|
2104
|
+
.PP
|
2105
|
+
Method 3: If the module to be embedded supports explicit event
|
2106
|
+
notification (adns does), you can also make use of the actual watcher
|
2107
|
+
callbacks, and only destroy/create the watchers in the prepare watcher.
|
2108
|
+
.PP
|
2109
|
+
.Vb 5
|
2110
|
+
\& static void
|
2111
|
+
\& timer_cb (EV_P_ ev_timer *w, int revents)
|
2112
|
+
\& {
|
2113
|
+
\& adns_state ads = (adns_state)w\->data;
|
2114
|
+
\& update_now (EV_A);
|
2115
|
+
\&
|
2116
|
+
\& adns_processtimeouts (ads, &tv_now);
|
2117
|
+
\& }
|
2118
|
+
\&
|
2119
|
+
\& static void
|
2120
|
+
\& io_cb (EV_P_ ev_io *w, int revents)
|
2121
|
+
\& {
|
2122
|
+
\& adns_state ads = (adns_state)w\->data;
|
2123
|
+
\& update_now (EV_A);
|
2124
|
+
\&
|
2125
|
+
\& if (revents & EV_READ ) adns_processreadable (ads, w\->fd, &tv_now);
|
2126
|
+
\& if (revents & EV_WRITE) adns_processwriteable (ads, w\->fd, &tv_now);
|
2127
|
+
\& }
|
2128
|
+
\&
|
2129
|
+
\& // do not ever call adns_afterpoll
|
2130
|
+
.Ve
|
2131
|
+
.PP
|
2132
|
+
Method 4: Do not use a prepare or check watcher because the module you
|
2133
|
+
want to embed is too inflexible to support it. Instead, youc na override
|
2134
|
+
their poll function. The drawback with this solution is that the main
|
2135
|
+
loop is now no longer controllable by \s-1EV\s0. The \f(CW\*(C`Glib::EV\*(C'\fR module does
|
2136
|
+
this.
|
2137
|
+
.PP
|
2138
|
+
.Vb 4
|
2139
|
+
\& static gint
|
2140
|
+
\& event_poll_func (GPollFD *fds, guint nfds, gint timeout)
|
2141
|
+
\& {
|
2142
|
+
\& int got_events = 0;
|
2143
|
+
\&
|
2144
|
+
\& for (n = 0; n < nfds; ++n)
|
2145
|
+
\& // create/start io watcher that sets the relevant bits in fds[n] and increment got_events
|
2146
|
+
\&
|
2147
|
+
\& if (timeout >= 0)
|
2148
|
+
\& // create/start timer
|
2149
|
+
\&
|
2150
|
+
\& // poll
|
2151
|
+
\& ev_loop (EV_A_ 0);
|
2152
|
+
\&
|
2153
|
+
\& // stop timer again
|
2154
|
+
\& if (timeout >= 0)
|
2155
|
+
\& ev_timer_stop (EV_A_ &to);
|
2156
|
+
\&
|
2157
|
+
\& // stop io watchers again \- their callbacks should have set
|
2158
|
+
\& for (n = 0; n < nfds; ++n)
|
2159
|
+
\& ev_io_stop (EV_A_ iow [n]);
|
2160
|
+
\&
|
2161
|
+
\& return got_events;
|
2162
|
+
\& }
|
2163
|
+
.Ve
|
2164
|
+
.ie n .Sh """ev_embed"" \- when one backend isn't enough..."
|
2165
|
+
.el .Sh "\f(CWev_embed\fP \- when one backend isn't enough..."
|
2166
|
+
.IX Subsection "ev_embed - when one backend isn't enough..."
|
2167
|
+
This is a rather advanced watcher type that lets you embed one event loop
|
2168
|
+
into another (currently only \f(CW\*(C`ev_io\*(C'\fR events are supported in the embedded
|
2169
|
+
loop, other types of watchers might be handled in a delayed or incorrect
|
2170
|
+
fashion and must not be used).
|
2171
|
+
.PP
|
2172
|
+
There are primarily two reasons you would want that: work around bugs and
|
2173
|
+
prioritise I/O.
|
2174
|
+
.PP
|
2175
|
+
As an example for a bug workaround, the kqueue backend might only support
|
2176
|
+
sockets on some platform, so it is unusable as generic backend, but you
|
2177
|
+
still want to make use of it because you have many sockets and it scales
|
2178
|
+
so nicely. In this case, you would create a kqueue-based loop and embed it
|
2179
|
+
into your default loop (which might use e.g. poll). Overall operation will
|
2180
|
+
be a bit slower because first libev has to poll and then call kevent, but
|
2181
|
+
at least you can use both at what they are best.
|
2182
|
+
.PP
|
2183
|
+
As for prioritising I/O: rarely you have the case where some fds have
|
2184
|
+
to be watched and handled very quickly (with low latency), and even
|
2185
|
+
priorities and idle watchers might have too much overhead. In this case
|
2186
|
+
you would put all the high priority stuff in one loop and all the rest in
|
2187
|
+
a second one, and embed the second one in the first.
|
2188
|
+
.PP
|
2189
|
+
As long as the watcher is active, the callback will be invoked every time
|
2190
|
+
there might be events pending in the embedded loop. The callback must then
|
2191
|
+
call \f(CW\*(C`ev_embed_sweep (mainloop, watcher)\*(C'\fR to make a single sweep and invoke
|
2192
|
+
their callbacks (you could also start an idle watcher to give the embedded
|
2193
|
+
loop strictly lower priority for example). You can also set the callback
|
2194
|
+
to \f(CW0\fR, in which case the embed watcher will automatically execute the
|
2195
|
+
embedded loop sweep.
|
2196
|
+
.PP
|
2197
|
+
As long as the watcher is started it will automatically handle events. The
|
2198
|
+
callback will be invoked whenever some events have been handled. You can
|
2199
|
+
set the callback to \f(CW0\fR to avoid having to specify one if you are not
|
2200
|
+
interested in that.
|
2201
|
+
.PP
|
2202
|
+
Also, there have not currently been made special provisions for forking:
|
2203
|
+
when you fork, you not only have to call \f(CW\*(C`ev_loop_fork\*(C'\fR on both loops,
|
2204
|
+
but you will also have to stop and restart any \f(CW\*(C`ev_embed\*(C'\fR watchers
|
2205
|
+
yourself.
|
2206
|
+
.PP
|
2207
|
+
Unfortunately, not all backends are embeddable, only the ones returned by
|
2208
|
+
\&\f(CW\*(C`ev_embeddable_backends\*(C'\fR are, which, unfortunately, does not include any
|
2209
|
+
portable one.
|
2210
|
+
.PP
|
2211
|
+
So when you want to use this feature you will always have to be prepared
|
2212
|
+
that you cannot get an embeddable loop. The recommended way to get around
|
2213
|
+
this is to have a separate variables for your embeddable loop, try to
|
2214
|
+
create it, and if that fails, use the normal loop for everything.
|
2215
|
+
.PP
|
2216
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
2217
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
2218
|
+
.IP "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)" 4
|
2219
|
+
.IX Item "ev_embed_init (ev_embed *, callback, struct ev_loop *embedded_loop)"
|
2220
|
+
.PD 0
|
2221
|
+
.IP "ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)" 4
|
2222
|
+
.IX Item "ev_embed_set (ev_embed *, callback, struct ev_loop *embedded_loop)"
|
2223
|
+
.PD
|
2224
|
+
Configures the watcher to embed the given loop, which must be
|
2225
|
+
embeddable. If the callback is \f(CW0\fR, then \f(CW\*(C`ev_embed_sweep\*(C'\fR will be
|
2226
|
+
invoked automatically, otherwise it is the responsibility of the callback
|
2227
|
+
to invoke it (it will continue to be called until the sweep has been done,
|
2228
|
+
if you do not want thta, you need to temporarily stop the embed watcher).
|
2229
|
+
.IP "ev_embed_sweep (loop, ev_embed *)" 4
|
2230
|
+
.IX Item "ev_embed_sweep (loop, ev_embed *)"
|
2231
|
+
Make a single, non-blocking sweep over the embedded loop. This works
|
2232
|
+
similarly to \f(CW\*(C`ev_loop (embedded_loop, EVLOOP_NONBLOCK)\*(C'\fR, but in the most
|
2233
|
+
apropriate way for embedded loops.
|
2234
|
+
.IP "struct ev_loop *other [read\-only]" 4
|
2235
|
+
.IX Item "struct ev_loop *other [read-only]"
|
2236
|
+
The embedded event loop.
|
2237
|
+
.PP
|
2238
|
+
\fIExamples\fR
|
2239
|
+
.IX Subsection "Examples"
|
2240
|
+
.PP
|
2241
|
+
Example: Try to get an embeddable event loop and embed it into the default
|
2242
|
+
event loop. If that is not possible, use the default loop. The default
|
2243
|
+
loop is stored in \f(CW\*(C`loop_hi\*(C'\fR, while the mebeddable loop is stored in
|
2244
|
+
\&\f(CW\*(C`loop_lo\*(C'\fR (which is \f(CW\*(C`loop_hi\*(C'\fR in the acse no embeddable loop can be
|
2245
|
+
used).
|
2246
|
+
.PP
|
2247
|
+
.Vb 3
|
2248
|
+
\& struct ev_loop *loop_hi = ev_default_init (0);
|
2249
|
+
\& struct ev_loop *loop_lo = 0;
|
2250
|
+
\& struct ev_embed embed;
|
2251
|
+
\&
|
2252
|
+
\& // see if there is a chance of getting one that works
|
2253
|
+
\& // (remember that a flags value of 0 means autodetection)
|
2254
|
+
\& loop_lo = ev_embeddable_backends () & ev_recommended_backends ()
|
2255
|
+
\& ? ev_loop_new (ev_embeddable_backends () & ev_recommended_backends ())
|
2256
|
+
\& : 0;
|
2257
|
+
\&
|
2258
|
+
\& // if we got one, then embed it, otherwise default to loop_hi
|
2259
|
+
\& if (loop_lo)
|
2260
|
+
\& {
|
2261
|
+
\& ev_embed_init (&embed, 0, loop_lo);
|
2262
|
+
\& ev_embed_start (loop_hi, &embed);
|
2263
|
+
\& }
|
2264
|
+
\& else
|
2265
|
+
\& loop_lo = loop_hi;
|
2266
|
+
.Ve
|
2267
|
+
.PP
|
2268
|
+
Example: Check if kqueue is available but not recommended and create
|
2269
|
+
a kqueue backend for use with sockets (which usually work with any
|
2270
|
+
kqueue implementation). Store the kqueue/socket\-only event loop in
|
2271
|
+
\&\f(CW\*(C`loop_socket\*(C'\fR. (One might optionally use \f(CW\*(C`EVFLAG_NOENV\*(C'\fR, too).
|
2272
|
+
.PP
|
2273
|
+
.Vb 3
|
2274
|
+
\& struct ev_loop *loop = ev_default_init (0);
|
2275
|
+
\& struct ev_loop *loop_socket = 0;
|
2276
|
+
\& struct ev_embed embed;
|
2277
|
+
\&
|
2278
|
+
\& if (ev_supported_backends () & ~ev_recommended_backends () & EVBACKEND_KQUEUE)
|
2279
|
+
\& if ((loop_socket = ev_loop_new (EVBACKEND_KQUEUE))
|
2280
|
+
\& {
|
2281
|
+
\& ev_embed_init (&embed, 0, loop_socket);
|
2282
|
+
\& ev_embed_start (loop, &embed);
|
2283
|
+
\& }
|
2284
|
+
\&
|
2285
|
+
\& if (!loop_socket)
|
2286
|
+
\& loop_socket = loop;
|
2287
|
+
\&
|
2288
|
+
\& // now use loop_socket for all sockets, and loop for everything else
|
2289
|
+
.Ve
|
2290
|
+
.ie n .Sh """ev_fork"" \- the audacity to resume the event loop after a fork"
|
2291
|
+
.el .Sh "\f(CWev_fork\fP \- the audacity to resume the event loop after a fork"
|
2292
|
+
.IX Subsection "ev_fork - the audacity to resume the event loop after a fork"
|
2293
|
+
Fork watchers are called when a \f(CW\*(C`fork ()\*(C'\fR was detected (usually because
|
2294
|
+
whoever is a good citizen cared to tell libev about it by calling
|
2295
|
+
\&\f(CW\*(C`ev_default_fork\*(C'\fR or \f(CW\*(C`ev_loop_fork\*(C'\fR). The invocation is done before the
|
2296
|
+
event loop blocks next and before \f(CW\*(C`ev_check\*(C'\fR watchers are being called,
|
2297
|
+
and only in the child after the fork. If whoever good citizen calling
|
2298
|
+
\&\f(CW\*(C`ev_default_fork\*(C'\fR cheats and calls it in the wrong process, the fork
|
2299
|
+
handlers will be invoked, too, of course.
|
2300
|
+
.PP
|
2301
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
2302
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
2303
|
+
.IP "ev_fork_init (ev_signal *, callback)" 4
|
2304
|
+
.IX Item "ev_fork_init (ev_signal *, callback)"
|
2305
|
+
Initialises and configures the fork watcher \- it has no parameters of any
|
2306
|
+
kind. There is a \f(CW\*(C`ev_fork_set\*(C'\fR macro, but using it is utterly pointless,
|
2307
|
+
believe me.
|
2308
|
+
.ie n .Sh """ev_async"" \- how to wake up another event loop"
|
2309
|
+
.el .Sh "\f(CWev_async\fP \- how to wake up another event loop"
|
2310
|
+
.IX Subsection "ev_async - how to wake up another event loop"
|
2311
|
+
In general, you cannot use an \f(CW\*(C`ev_loop\*(C'\fR from multiple threads or other
|
2312
|
+
asynchronous sources such as signal handlers (as opposed to multiple event
|
2313
|
+
loops \- those are of course safe to use in different threads).
|
2314
|
+
.PP
|
2315
|
+
Sometimes, however, you need to wake up another event loop you do not
|
2316
|
+
control, for example because it belongs to another thread. This is what
|
2317
|
+
\&\f(CW\*(C`ev_async\*(C'\fR watchers do: as long as the \f(CW\*(C`ev_async\*(C'\fR watcher is active, you
|
2318
|
+
can signal it by calling \f(CW\*(C`ev_async_send\*(C'\fR, which is thread\- and signal
|
2319
|
+
safe.
|
2320
|
+
.PP
|
2321
|
+
This functionality is very similar to \f(CW\*(C`ev_signal\*(C'\fR watchers, as signals,
|
2322
|
+
too, are asynchronous in nature, and signals, too, will be compressed
|
2323
|
+
(i.e. the number of callback invocations may be less than the number of
|
2324
|
+
\&\f(CW\*(C`ev_async_sent\*(C'\fR calls).
|
2325
|
+
.PP
|
2326
|
+
Unlike \f(CW\*(C`ev_signal\*(C'\fR watchers, \f(CW\*(C`ev_async\*(C'\fR works with any event loop, not
|
2327
|
+
just the default loop.
|
2328
|
+
.PP
|
2329
|
+
\fIQueueing\fR
|
2330
|
+
.IX Subsection "Queueing"
|
2331
|
+
.PP
|
2332
|
+
\&\f(CW\*(C`ev_async\*(C'\fR does not support queueing of data in any way. The reason
|
2333
|
+
is that the author does not know of a simple (or any) algorithm for a
|
2334
|
+
multiple-writer-single-reader queue that works in all cases and doesn't
|
2335
|
+
need elaborate support such as pthreads.
|
2336
|
+
.PP
|
2337
|
+
That means that if you want to queue data, you have to provide your own
|
2338
|
+
queue. But at least I can tell you would implement locking around your
|
2339
|
+
queue:
|
2340
|
+
.IP "queueing from a signal handler context" 4
|
2341
|
+
.IX Item "queueing from a signal handler context"
|
2342
|
+
To implement race-free queueing, you simply add to the queue in the signal
|
2343
|
+
handler but you block the signal handler in the watcher callback. Here is an example that does that for
|
2344
|
+
some fictitiuous \s-1SIGUSR1\s0 handler:
|
2345
|
+
.Sp
|
2346
|
+
.Vb 1
|
2347
|
+
\& static ev_async mysig;
|
2348
|
+
\&
|
2349
|
+
\& static void
|
2350
|
+
\& sigusr1_handler (void)
|
2351
|
+
\& {
|
2352
|
+
\& sometype data;
|
2353
|
+
\&
|
2354
|
+
\& // no locking etc.
|
2355
|
+
\& queue_put (data);
|
2356
|
+
\& ev_async_send (EV_DEFAULT_ &mysig);
|
2357
|
+
\& }
|
2358
|
+
\&
|
2359
|
+
\& static void
|
2360
|
+
\& mysig_cb (EV_P_ ev_async *w, int revents)
|
2361
|
+
\& {
|
2362
|
+
\& sometype data;
|
2363
|
+
\& sigset_t block, prev;
|
2364
|
+
\&
|
2365
|
+
\& sigemptyset (&block);
|
2366
|
+
\& sigaddset (&block, SIGUSR1);
|
2367
|
+
\& sigprocmask (SIG_BLOCK, &block, &prev);
|
2368
|
+
\&
|
2369
|
+
\& while (queue_get (&data))
|
2370
|
+
\& process (data);
|
2371
|
+
\&
|
2372
|
+
\& if (sigismember (&prev, SIGUSR1)
|
2373
|
+
\& sigprocmask (SIG_UNBLOCK, &block, 0);
|
2374
|
+
\& }
|
2375
|
+
.Ve
|
2376
|
+
.Sp
|
2377
|
+
(Note: pthreads in theory requires you to use \f(CW\*(C`pthread_setmask\*(C'\fR
|
2378
|
+
instead of \f(CW\*(C`sigprocmask\*(C'\fR when you use threads, but libev doesn't do it
|
2379
|
+
either...).
|
2380
|
+
.IP "queueing from a thread context" 4
|
2381
|
+
.IX Item "queueing from a thread context"
|
2382
|
+
The strategy for threads is different, as you cannot (easily) block
|
2383
|
+
threads but you can easily preempt them, so to queue safely you need to
|
2384
|
+
employ a traditional mutex lock, such as in this pthread example:
|
2385
|
+
.Sp
|
2386
|
+
.Vb 2
|
2387
|
+
\& static ev_async mysig;
|
2388
|
+
\& static pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
|
2389
|
+
\&
|
2390
|
+
\& static void
|
2391
|
+
\& otherthread (void)
|
2392
|
+
\& {
|
2393
|
+
\& // only need to lock the actual queueing operation
|
2394
|
+
\& pthread_mutex_lock (&mymutex);
|
2395
|
+
\& queue_put (data);
|
2396
|
+
\& pthread_mutex_unlock (&mymutex);
|
2397
|
+
\&
|
2398
|
+
\& ev_async_send (EV_DEFAULT_ &mysig);
|
2399
|
+
\& }
|
2400
|
+
\&
|
2401
|
+
\& static void
|
2402
|
+
\& mysig_cb (EV_P_ ev_async *w, int revents)
|
2403
|
+
\& {
|
2404
|
+
\& pthread_mutex_lock (&mymutex);
|
2405
|
+
\&
|
2406
|
+
\& while (queue_get (&data))
|
2407
|
+
\& process (data);
|
2408
|
+
\&
|
2409
|
+
\& pthread_mutex_unlock (&mymutex);
|
2410
|
+
\& }
|
2411
|
+
.Ve
|
2412
|
+
.PP
|
2413
|
+
\fIWatcher-Specific Functions and Data Members\fR
|
2414
|
+
.IX Subsection "Watcher-Specific Functions and Data Members"
|
2415
|
+
.IP "ev_async_init (ev_async *, callback)" 4
|
2416
|
+
.IX Item "ev_async_init (ev_async *, callback)"
|
2417
|
+
Initialises and configures the async watcher \- it has no parameters of any
|
2418
|
+
kind. There is a \f(CW\*(C`ev_asynd_set\*(C'\fR macro, but using it is utterly pointless,
|
2419
|
+
believe me.
|
2420
|
+
.IP "ev_async_send (loop, ev_async *)" 4
|
2421
|
+
.IX Item "ev_async_send (loop, ev_async *)"
|
2422
|
+
Sends/signals/activates the given \f(CW\*(C`ev_async\*(C'\fR watcher, that is, feeds
|
2423
|
+
an \f(CW\*(C`EV_ASYNC\*(C'\fR event on the watcher into the event loop. Unlike
|
2424
|
+
\&\f(CW\*(C`ev_feed_event\*(C'\fR, this call is safe to do in other threads, signal or
|
2425
|
+
similar contexts (see the dicusssion of \f(CW\*(C`EV_ATOMIC_T\*(C'\fR in the embedding
|
2426
|
+
section below on what exactly this means).
|
2427
|
+
.Sp
|
2428
|
+
This call incurs the overhead of a syscall only once per loop iteration,
|
2429
|
+
so while the overhead might be noticable, it doesn't apply to repeated
|
2430
|
+
calls to \f(CW\*(C`ev_async_send\*(C'\fR.
|
2431
|
+
.IP "bool = ev_async_pending (ev_async *)" 4
|
2432
|
+
.IX Item "bool = ev_async_pending (ev_async *)"
|
2433
|
+
Returns a non-zero value when \f(CW\*(C`ev_async_send\*(C'\fR has been called on the
|
2434
|
+
watcher but the event has not yet been processed (or even noted) by the
|
2435
|
+
event loop.
|
2436
|
+
.Sp
|
2437
|
+
\&\f(CW\*(C`ev_async_send\*(C'\fR sets a flag in the watcher and wakes up the loop. When
|
2438
|
+
the loop iterates next and checks for the watcher to have become active,
|
2439
|
+
it will reset the flag again. \f(CW\*(C`ev_async_pending\*(C'\fR can be used to very
|
2440
|
+
quickly check wether invoking the loop might be a good idea.
|
2441
|
+
.Sp
|
2442
|
+
Not that this does \fInot\fR check wether the watcher itself is pending, only
|
2443
|
+
wether it has been requested to make this watcher pending.
|
2444
|
+
.SH "OTHER FUNCTIONS"
|
2445
|
+
.IX Header "OTHER FUNCTIONS"
|
2446
|
+
There are some other functions of possible interest. Described. Here. Now.
|
2447
|
+
.IP "ev_once (loop, int fd, int events, ev_tstamp timeout, callback)" 4
|
2448
|
+
.IX Item "ev_once (loop, int fd, int events, ev_tstamp timeout, callback)"
|
2449
|
+
This function combines a simple timer and an I/O watcher, calls your
|
2450
|
+
callback on whichever event happens first and automatically stop both
|
2451
|
+
watchers. This is useful if you want to wait for a single event on an fd
|
2452
|
+
or timeout without having to allocate/configure/start/stop/free one or
|
2453
|
+
more watchers yourself.
|
2454
|
+
.Sp
|
2455
|
+
If \f(CW\*(C`fd\*(C'\fR is less than 0, then no I/O watcher will be started and events
|
2456
|
+
is being ignored. Otherwise, an \f(CW\*(C`ev_io\*(C'\fR watcher for the given \f(CW\*(C`fd\*(C'\fR and
|
2457
|
+
\&\f(CW\*(C`events\*(C'\fR set will be craeted and started.
|
2458
|
+
.Sp
|
2459
|
+
If \f(CW\*(C`timeout\*(C'\fR is less than 0, then no timeout watcher will be
|
2460
|
+
started. Otherwise an \f(CW\*(C`ev_timer\*(C'\fR watcher with after = \f(CW\*(C`timeout\*(C'\fR (and
|
2461
|
+
repeat = 0) will be started. While \f(CW0\fR is a valid timeout, it is of
|
2462
|
+
dubious value.
|
2463
|
+
.Sp
|
2464
|
+
The callback has the type \f(CW\*(C`void (*cb)(int revents, void *arg)\*(C'\fR and gets
|
2465
|
+
passed an \f(CW\*(C`revents\*(C'\fR set like normal event callbacks (a combination of
|
2466
|
+
\&\f(CW\*(C`EV_ERROR\*(C'\fR, \f(CW\*(C`EV_READ\*(C'\fR, \f(CW\*(C`EV_WRITE\*(C'\fR or \f(CW\*(C`EV_TIMEOUT\*(C'\fR) and the \f(CW\*(C`arg\*(C'\fR
|
2467
|
+
value passed to \f(CW\*(C`ev_once\*(C'\fR:
|
2468
|
+
.Sp
|
2469
|
+
.Vb 7
|
2470
|
+
\& static void stdin_ready (int revents, void *arg)
|
2471
|
+
\& {
|
2472
|
+
\& if (revents & EV_TIMEOUT)
|
2473
|
+
\& /* doh, nothing entered */;
|
2474
|
+
\& else if (revents & EV_READ)
|
2475
|
+
\& /* stdin might have data for us, joy! */;
|
2476
|
+
\& }
|
2477
|
+
\&
|
2478
|
+
\& ev_once (STDIN_FILENO, EV_READ, 10., stdin_ready, 0);
|
2479
|
+
.Ve
|
2480
|
+
.IP "ev_feed_event (ev_loop *, watcher *, int revents)" 4
|
2481
|
+
.IX Item "ev_feed_event (ev_loop *, watcher *, int revents)"
|
2482
|
+
Feeds the given event set into the event loop, as if the specified event
|
2483
|
+
had happened for the specified watcher (which must be a pointer to an
|
2484
|
+
initialised but not necessarily started event watcher).
|
2485
|
+
.IP "ev_feed_fd_event (ev_loop *, int fd, int revents)" 4
|
2486
|
+
.IX Item "ev_feed_fd_event (ev_loop *, int fd, int revents)"
|
2487
|
+
Feed an event on the given fd, as if a file descriptor backend detected
|
2488
|
+
the given events it.
|
2489
|
+
.IP "ev_feed_signal_event (ev_loop *loop, int signum)" 4
|
2490
|
+
.IX Item "ev_feed_signal_event (ev_loop *loop, int signum)"
|
2491
|
+
Feed an event as if the given signal occured (\f(CW\*(C`loop\*(C'\fR must be the default
|
2492
|
+
loop!).
|
2493
|
+
.SH "LIBEVENT EMULATION"
|
2494
|
+
.IX Header "LIBEVENT EMULATION"
|
2495
|
+
Libev offers a compatibility emulation layer for libevent. It cannot
|
2496
|
+
emulate the internals of libevent, so here are some usage hints:
|
2497
|
+
.IP "\(bu" 4
|
2498
|
+
Use it by including <event.h>, as usual.
|
2499
|
+
.IP "\(bu" 4
|
2500
|
+
The following members are fully supported: ev_base, ev_callback,
|
2501
|
+
ev_arg, ev_fd, ev_res, ev_events.
|
2502
|
+
.IP "\(bu" 4
|
2503
|
+
Avoid using ev_flags and the EVLIST_*\-macros, while it is
|
2504
|
+
maintained by libev, it does not work exactly the same way as in libevent (consider
|
2505
|
+
it a private \s-1API\s0).
|
2506
|
+
.IP "\(bu" 4
|
2507
|
+
Priorities are not currently supported. Initialising priorities
|
2508
|
+
will fail and all watchers will have the same priority, even though there
|
2509
|
+
is an ev_pri field.
|
2510
|
+
.IP "\(bu" 4
|
2511
|
+
In libevent, the last base created gets the signals, in libev, the
|
2512
|
+
first base created (== the default loop) gets the signals.
|
2513
|
+
.IP "\(bu" 4
|
2514
|
+
Other members are not supported.
|
2515
|
+
.IP "\(bu" 4
|
2516
|
+
The libev emulation is \fInot\fR \s-1ABI\s0 compatible to libevent, you need
|
2517
|
+
to use the libev header file and library.
|
2518
|
+
.SH "\*(C+ SUPPORT"
|
2519
|
+
.IX Header " SUPPORT"
|
2520
|
+
Libev comes with some simplistic wrapper classes for \*(C+ that mainly allow
|
2521
|
+
you to use some convinience methods to start/stop watchers and also change
|
2522
|
+
the callback model to a model using method callbacks on objects.
|
2523
|
+
.PP
|
2524
|
+
To use it,
|
2525
|
+
.PP
|
2526
|
+
.Vb 1
|
2527
|
+
\& #include <ev++.h>
|
2528
|
+
.Ve
|
2529
|
+
.PP
|
2530
|
+
This automatically includes \fIev.h\fR and puts all of its definitions (many
|
2531
|
+
of them macros) into the global namespace. All \*(C+ specific things are
|
2532
|
+
put into the \f(CW\*(C`ev\*(C'\fR namespace. It should support all the same embedding
|
2533
|
+
options as \fIev.h\fR, most notably \f(CW\*(C`EV_MULTIPLICITY\*(C'\fR.
|
2534
|
+
.PP
|
2535
|
+
Care has been taken to keep the overhead low. The only data member the \*(C+
|
2536
|
+
classes add (compared to plain C\-style watchers) is the event loop pointer
|
2537
|
+
that the watcher is associated with (or no additional members at all if
|
2538
|
+
you disable \f(CW\*(C`EV_MULTIPLICITY\*(C'\fR when embedding libev).
|
2539
|
+
.PP
|
2540
|
+
Currently, functions, and static and non-static member functions can be
|
2541
|
+
used as callbacks. Other types should be easy to add as long as they only
|
2542
|
+
need one additional pointer for context. If you need support for other
|
2543
|
+
types of functors please contact the author (preferably after implementing
|
2544
|
+
it).
|
2545
|
+
.PP
|
2546
|
+
Here is a list of things available in the \f(CW\*(C`ev\*(C'\fR namespace:
|
2547
|
+
.ie n .IP """ev::READ""\fR, \f(CW""ev::WRITE"" etc." 4
|
2548
|
+
.el .IP "\f(CWev::READ\fR, \f(CWev::WRITE\fR etc." 4
|
2549
|
+
.IX Item "ev::READ, ev::WRITE etc."
|
2550
|
+
These are just enum values with the same values as the \f(CW\*(C`EV_READ\*(C'\fR etc.
|
2551
|
+
macros from \fIev.h\fR.
|
2552
|
+
.ie n .IP """ev::tstamp""\fR, \f(CW""ev::now""" 4
|
2553
|
+
.el .IP "\f(CWev::tstamp\fR, \f(CWev::now\fR" 4
|
2554
|
+
.IX Item "ev::tstamp, ev::now"
|
2555
|
+
Aliases to the same types/functions as with the \f(CW\*(C`ev_\*(C'\fR prefix.
|
2556
|
+
.ie n .IP """ev::io""\fR, \f(CW""ev::timer""\fR, \f(CW""ev::periodic""\fR, \f(CW""ev::idle""\fR, \f(CW""ev::sig"" etc." 4
|
2557
|
+
.el .IP "\f(CWev::io\fR, \f(CWev::timer\fR, \f(CWev::periodic\fR, \f(CWev::idle\fR, \f(CWev::sig\fR etc." 4
|
2558
|
+
.IX Item "ev::io, ev::timer, ev::periodic, ev::idle, ev::sig etc."
|
2559
|
+
For each \f(CW\*(C`ev_TYPE\*(C'\fR watcher in \fIev.h\fR there is a corresponding class of
|
2560
|
+
the same name in the \f(CW\*(C`ev\*(C'\fR namespace, with the exception of \f(CW\*(C`ev_signal\*(C'\fR
|
2561
|
+
which is called \f(CW\*(C`ev::sig\*(C'\fR to avoid clashes with the \f(CW\*(C`signal\*(C'\fR macro
|
2562
|
+
defines by many implementations.
|
2563
|
+
.Sp
|
2564
|
+
All of those classes have these methods:
|
2565
|
+
.RS 4
|
2566
|
+
.IP "ev::TYPE::TYPE ()" 4
|
2567
|
+
.IX Item "ev::TYPE::TYPE ()"
|
2568
|
+
.PD 0
|
2569
|
+
.IP "ev::TYPE::TYPE (struct ev_loop *)" 4
|
2570
|
+
.IX Item "ev::TYPE::TYPE (struct ev_loop *)"
|
2571
|
+
.IP "ev::TYPE::~TYPE" 4
|
2572
|
+
.IX Item "ev::TYPE::~TYPE"
|
2573
|
+
.PD
|
2574
|
+
The constructor (optionally) takes an event loop to associate the watcher
|
2575
|
+
with. If it is omitted, it will use \f(CW\*(C`EV_DEFAULT\*(C'\fR.
|
2576
|
+
.Sp
|
2577
|
+
The constructor calls \f(CW\*(C`ev_init\*(C'\fR for you, which means you have to call the
|
2578
|
+
\&\f(CW\*(C`set\*(C'\fR method before starting it.
|
2579
|
+
.Sp
|
2580
|
+
It will not set a callback, however: You have to call the templated \f(CW\*(C`set\*(C'\fR
|
2581
|
+
method to set a callback before you can start the watcher.
|
2582
|
+
.Sp
|
2583
|
+
(The reason why you have to use a method is a limitation in \*(C+ which does
|
2584
|
+
not allow explicit template arguments for constructors).
|
2585
|
+
.Sp
|
2586
|
+
The destructor automatically stops the watcher if it is active.
|
2587
|
+
.IP "w\->set<class, &class::method> (object *)" 4
|
2588
|
+
.IX Item "w->set<class, &class::method> (object *)"
|
2589
|
+
This method sets the callback method to call. The method has to have a
|
2590
|
+
signature of \f(CW\*(C`void (*)(ev_TYPE &, int)\*(C'\fR, it receives the watcher as
|
2591
|
+
first argument and the \f(CW\*(C`revents\*(C'\fR as second. The object must be given as
|
2592
|
+
parameter and is stored in the \f(CW\*(C`data\*(C'\fR member of the watcher.
|
2593
|
+
.Sp
|
2594
|
+
This method synthesizes efficient thunking code to call your method from
|
2595
|
+
the C callback that libev requires. If your compiler can inline your
|
2596
|
+
callback (i.e. it is visible to it at the place of the \f(CW\*(C`set\*(C'\fR call and
|
2597
|
+
your compiler is good :), then the method will be fully inlined into the
|
2598
|
+
thunking function, making it as fast as a direct C callback.
|
2599
|
+
.Sp
|
2600
|
+
Example: simple class declaration and watcher initialisation
|
2601
|
+
.Sp
|
2602
|
+
.Vb 4
|
2603
|
+
\& struct myclass
|
2604
|
+
\& {
|
2605
|
+
\& void io_cb (ev::io &w, int revents) { }
|
2606
|
+
\& }
|
2607
|
+
\&
|
2608
|
+
\& myclass obj;
|
2609
|
+
\& ev::io iow;
|
2610
|
+
\& iow.set <myclass, &myclass::io_cb> (&obj);
|
2611
|
+
.Ve
|
2612
|
+
.IP "w\->set<function> (void *data = 0)" 4
|
2613
|
+
.IX Item "w->set<function> (void *data = 0)"
|
2614
|
+
Also sets a callback, but uses a static method or plain function as
|
2615
|
+
callback. The optional \f(CW\*(C`data\*(C'\fR argument will be stored in the watcher's
|
2616
|
+
\&\f(CW\*(C`data\*(C'\fR member and is free for you to use.
|
2617
|
+
.Sp
|
2618
|
+
The prototype of the \f(CW\*(C`function\*(C'\fR must be \f(CW\*(C`void (*)(ev::TYPE &w, int)\*(C'\fR.
|
2619
|
+
.Sp
|
2620
|
+
See the method\-\f(CW\*(C`set\*(C'\fR above for more details.
|
2621
|
+
.Sp
|
2622
|
+
Example:
|
2623
|
+
.Sp
|
2624
|
+
.Vb 2
|
2625
|
+
\& static void io_cb (ev::io &w, int revents) { }
|
2626
|
+
\& iow.set <io_cb> ();
|
2627
|
+
.Ve
|
2628
|
+
.IP "w\->set (struct ev_loop *)" 4
|
2629
|
+
.IX Item "w->set (struct ev_loop *)"
|
2630
|
+
Associates a different \f(CW\*(C`struct ev_loop\*(C'\fR with this watcher. You can only
|
2631
|
+
do this when the watcher is inactive (and not pending either).
|
2632
|
+
.IP "w\->set ([args])" 4
|
2633
|
+
.IX Item "w->set ([args])"
|
2634
|
+
Basically the same as \f(CW\*(C`ev_TYPE_set\*(C'\fR, with the same args. Must be
|
2635
|
+
called at least once. Unlike the C counterpart, an active watcher gets
|
2636
|
+
automatically stopped and restarted when reconfiguring it with this
|
2637
|
+
method.
|
2638
|
+
.IP "w\->start ()" 4
|
2639
|
+
.IX Item "w->start ()"
|
2640
|
+
Starts the watcher. Note that there is no \f(CW\*(C`loop\*(C'\fR argument, as the
|
2641
|
+
constructor already stores the event loop.
|
2642
|
+
.IP "w\->stop ()" 4
|
2643
|
+
.IX Item "w->stop ()"
|
2644
|
+
Stops the watcher if it is active. Again, no \f(CW\*(C`loop\*(C'\fR argument.
|
2645
|
+
.ie n .IP "w\->again () (""ev::timer""\fR, \f(CW""ev::periodic"" only)" 4
|
2646
|
+
.el .IP "w\->again () (\f(CWev::timer\fR, \f(CWev::periodic\fR only)" 4
|
2647
|
+
.IX Item "w->again () (ev::timer, ev::periodic only)"
|
2648
|
+
For \f(CW\*(C`ev::timer\*(C'\fR and \f(CW\*(C`ev::periodic\*(C'\fR, this invokes the corresponding
|
2649
|
+
\&\f(CW\*(C`ev_TYPE_again\*(C'\fR function.
|
2650
|
+
.ie n .IP "w\->sweep () (""ev::embed"" only)" 4
|
2651
|
+
.el .IP "w\->sweep () (\f(CWev::embed\fR only)" 4
|
2652
|
+
.IX Item "w->sweep () (ev::embed only)"
|
2653
|
+
Invokes \f(CW\*(C`ev_embed_sweep\*(C'\fR.
|
2654
|
+
.ie n .IP "w\->update () (""ev::stat"" only)" 4
|
2655
|
+
.el .IP "w\->update () (\f(CWev::stat\fR only)" 4
|
2656
|
+
.IX Item "w->update () (ev::stat only)"
|
2657
|
+
Invokes \f(CW\*(C`ev_stat_stat\*(C'\fR.
|
2658
|
+
.RE
|
2659
|
+
.RS 4
|
2660
|
+
.RE
|
2661
|
+
.PP
|
2662
|
+
Example: Define a class with an \s-1IO\s0 and idle watcher, start one of them in
|
2663
|
+
the constructor.
|
2664
|
+
.PP
|
2665
|
+
.Vb 4
|
2666
|
+
\& class myclass
|
2667
|
+
\& {
|
2668
|
+
\& ev::io io; void io_cb (ev::io &w, int revents);
|
2669
|
+
\& ev:idle idle void idle_cb (ev::idle &w, int revents);
|
2670
|
+
\&
|
2671
|
+
\& myclass (int fd)
|
2672
|
+
\& {
|
2673
|
+
\& io .set <myclass, &myclass::io_cb > (this);
|
2674
|
+
\& idle.set <myclass, &myclass::idle_cb> (this);
|
2675
|
+
\&
|
2676
|
+
\& io.start (fd, ev::READ);
|
2677
|
+
\& }
|
2678
|
+
\& };
|
2679
|
+
.Ve
|
2680
|
+
.SH "OTHER LANGUAGE BINDINGS"
|
2681
|
+
.IX Header "OTHER LANGUAGE BINDINGS"
|
2682
|
+
Libev does not offer other language bindings itself, but bindings for a
|
2683
|
+
numbe rof languages exist in the form of third-party packages. If you know
|
2684
|
+
any interesting language binding in addition to the ones listed here, drop
|
2685
|
+
me a note.
|
2686
|
+
.IP "Perl" 4
|
2687
|
+
.IX Item "Perl"
|
2688
|
+
The \s-1EV\s0 module implements the full libev \s-1API\s0 and is actually used to test
|
2689
|
+
libev. \s-1EV\s0 is developed together with libev. Apart from the \s-1EV\s0 core module,
|
2690
|
+
there are additional modules that implement libev-compatible interfaces
|
2691
|
+
to \f(CW\*(C`libadns\*(C'\fR (\f(CW\*(C`EV::ADNS\*(C'\fR), \f(CW\*(C`Net::SNMP\*(C'\fR (\f(CW\*(C`Net::SNMP::EV\*(C'\fR) and the
|
2692
|
+
\&\f(CW\*(C`libglib\*(C'\fR event core (\f(CW\*(C`Glib::EV\*(C'\fR and \f(CW\*(C`EV::Glib\*(C'\fR).
|
2693
|
+
.Sp
|
2694
|
+
It can be found and installed via \s-1CPAN\s0, its homepage is found at
|
2695
|
+
<http://software.schmorp.de/pkg/EV>.
|
2696
|
+
.IP "Ruby" 4
|
2697
|
+
.IX Item "Ruby"
|
2698
|
+
Tony Arcieri has written a ruby extension that offers access to a subset
|
2699
|
+
of the libev \s-1API\s0 and adds filehandle abstractions, asynchronous \s-1DNS\s0 and
|
2700
|
+
more on top of it. It can be found via gem servers. Its homepage is at
|
2701
|
+
<http://rev.rubyforge.org/>.
|
2702
|
+
.IP "D" 4
|
2703
|
+
.IX Item "D"
|
2704
|
+
Leandro Lucarella has written a D language binding (\fIev.d\fR) for libev, to
|
2705
|
+
be found at <http://git.llucax.com.ar/?p=software/ev.d.git;a=summary>.
|
2706
|
+
.SH "MACRO MAGIC"
|
2707
|
+
.IX Header "MACRO MAGIC"
|
2708
|
+
Libev can be compiled with a variety of options, the most fundamantal
|
2709
|
+
of which is \f(CW\*(C`EV_MULTIPLICITY\*(C'\fR. This option determines whether (most)
|
2710
|
+
functions and callbacks have an initial \f(CW\*(C`struct ev_loop *\*(C'\fR argument.
|
2711
|
+
.PP
|
2712
|
+
To make it easier to write programs that cope with either variant, the
|
2713
|
+
following macros are defined:
|
2714
|
+
.ie n .IP """EV_A""\fR, \f(CW""EV_A_""" 4
|
2715
|
+
.el .IP "\f(CWEV_A\fR, \f(CWEV_A_\fR" 4
|
2716
|
+
.IX Item "EV_A, EV_A_"
|
2717
|
+
This provides the loop \fIargument\fR for functions, if one is required (\*(L"ev
|
2718
|
+
loop argument\*(R"). The \f(CW\*(C`EV_A\*(C'\fR form is used when this is the sole argument,
|
2719
|
+
\&\f(CW\*(C`EV_A_\*(C'\fR is used when other arguments are following. Example:
|
2720
|
+
.Sp
|
2721
|
+
.Vb 3
|
2722
|
+
\& ev_unref (EV_A);
|
2723
|
+
\& ev_timer_add (EV_A_ watcher);
|
2724
|
+
\& ev_loop (EV_A_ 0);
|
2725
|
+
.Ve
|
2726
|
+
.Sp
|
2727
|
+
It assumes the variable \f(CW\*(C`loop\*(C'\fR of type \f(CW\*(C`struct ev_loop *\*(C'\fR is in scope,
|
2728
|
+
which is often provided by the following macro.
|
2729
|
+
.ie n .IP """EV_P""\fR, \f(CW""EV_P_""" 4
|
2730
|
+
.el .IP "\f(CWEV_P\fR, \f(CWEV_P_\fR" 4
|
2731
|
+
.IX Item "EV_P, EV_P_"
|
2732
|
+
This provides the loop \fIparameter\fR for functions, if one is required (\*(L"ev
|
2733
|
+
loop parameter\*(R"). The \f(CW\*(C`EV_P\*(C'\fR form is used when this is the sole parameter,
|
2734
|
+
\&\f(CW\*(C`EV_P_\*(C'\fR is used when other parameters are following. Example:
|
2735
|
+
.Sp
|
2736
|
+
.Vb 2
|
2737
|
+
\& // this is how ev_unref is being declared
|
2738
|
+
\& static void ev_unref (EV_P);
|
2739
|
+
\&
|
2740
|
+
\& // this is how you can declare your typical callback
|
2741
|
+
\& static void cb (EV_P_ ev_timer *w, int revents)
|
2742
|
+
.Ve
|
2743
|
+
.Sp
|
2744
|
+
It declares a parameter \f(CW\*(C`loop\*(C'\fR of type \f(CW\*(C`struct ev_loop *\*(C'\fR, quite
|
2745
|
+
suitable for use with \f(CW\*(C`EV_A\*(C'\fR.
|
2746
|
+
.ie n .IP """EV_DEFAULT""\fR, \f(CW""EV_DEFAULT_""" 4
|
2747
|
+
.el .IP "\f(CWEV_DEFAULT\fR, \f(CWEV_DEFAULT_\fR" 4
|
2748
|
+
.IX Item "EV_DEFAULT, EV_DEFAULT_"
|
2749
|
+
Similar to the other two macros, this gives you the value of the default
|
2750
|
+
loop, if multiple loops are supported (\*(L"ev loop default\*(R").
|
2751
|
+
.ie n .IP """EV_DEFAULT_UC""\fR, \f(CW""EV_DEFAULT_UC_""" 4
|
2752
|
+
.el .IP "\f(CWEV_DEFAULT_UC\fR, \f(CWEV_DEFAULT_UC_\fR" 4
|
2753
|
+
.IX Item "EV_DEFAULT_UC, EV_DEFAULT_UC_"
|
2754
|
+
Usage identical to \f(CW\*(C`EV_DEFAULT\*(C'\fR and \f(CW\*(C`EV_DEFAULT_\*(C'\fR, but requires that the
|
2755
|
+
default loop has been initialised (\f(CW\*(C`UC\*(C'\fR == unchecked). Their behaviour
|
2756
|
+
is undefined when the default loop has not been initialised by a previous
|
2757
|
+
execution of \f(CW\*(C`EV_DEFAULT\*(C'\fR, \f(CW\*(C`EV_DEFAULT_\*(C'\fR or \f(CW\*(C`ev_default_init (...)\*(C'\fR.
|
2758
|
+
.Sp
|
2759
|
+
It is often prudent to use \f(CW\*(C`EV_DEFAULT\*(C'\fR when initialising the first
|
2760
|
+
watcher in a function but use \f(CW\*(C`EV_DEFAULT_UC\*(C'\fR afterwards.
|
2761
|
+
.PP
|
2762
|
+
Example: Declare and initialise a check watcher, utilising the above
|
2763
|
+
macros so it will work regardless of whether multiple loops are supported
|
2764
|
+
or not.
|
2765
|
+
.PP
|
2766
|
+
.Vb 5
|
2767
|
+
\& static void
|
2768
|
+
\& check_cb (EV_P_ ev_timer *w, int revents)
|
2769
|
+
\& {
|
2770
|
+
\& ev_check_stop (EV_A_ w);
|
2771
|
+
\& }
|
2772
|
+
\&
|
2773
|
+
\& ev_check check;
|
2774
|
+
\& ev_check_init (&check, check_cb);
|
2775
|
+
\& ev_check_start (EV_DEFAULT_ &check);
|
2776
|
+
\& ev_loop (EV_DEFAULT_ 0);
|
2777
|
+
.Ve
|
2778
|
+
.SH "EMBEDDING"
|
2779
|
+
.IX Header "EMBEDDING"
|
2780
|
+
Libev can (and often is) directly embedded into host
|
2781
|
+
applications. Examples of applications that embed it include the Deliantra
|
2782
|
+
Game Server, the \s-1EV\s0 perl module, the \s-1GNU\s0 Virtual Private Ethernet (gvpe)
|
2783
|
+
and rxvt-unicode.
|
2784
|
+
.PP
|
2785
|
+
The goal is to enable you to just copy the necessary files into your
|
2786
|
+
source directory without having to change even a single line in them, so
|
2787
|
+
you can easily upgrade by simply copying (or having a checked-out copy of
|
2788
|
+
libev somewhere in your source tree).
|
2789
|
+
.Sh "\s-1FILESETS\s0"
|
2790
|
+
.IX Subsection "FILESETS"
|
2791
|
+
Depending on what features you need you need to include one or more sets of files
|
2792
|
+
in your app.
|
2793
|
+
.PP
|
2794
|
+
\fI\s-1CORE\s0 \s-1EVENT\s0 \s-1LOOP\s0\fR
|
2795
|
+
.IX Subsection "CORE EVENT LOOP"
|
2796
|
+
.PP
|
2797
|
+
To include only the libev core (all the \f(CW\*(C`ev_*\*(C'\fR functions), with manual
|
2798
|
+
configuration (no autoconf):
|
2799
|
+
.PP
|
2800
|
+
.Vb 2
|
2801
|
+
\& #define EV_STANDALONE 1
|
2802
|
+
\& #include "ev.c"
|
2803
|
+
.Ve
|
2804
|
+
.PP
|
2805
|
+
This will automatically include \fIev.h\fR, too, and should be done in a
|
2806
|
+
single C source file only to provide the function implementations. To use
|
2807
|
+
it, do the same for \fIev.h\fR in all files wishing to use this \s-1API\s0 (best
|
2808
|
+
done by writing a wrapper around \fIev.h\fR that you can include instead and
|
2809
|
+
where you can put other configuration options):
|
2810
|
+
.PP
|
2811
|
+
.Vb 2
|
2812
|
+
\& #define EV_STANDALONE 1
|
2813
|
+
\& #include "ev.h"
|
2814
|
+
.Ve
|
2815
|
+
.PP
|
2816
|
+
Both header files and implementation files can be compiled with a \*(C+
|
2817
|
+
compiler (at least, thats a stated goal, and breakage will be treated
|
2818
|
+
as a bug).
|
2819
|
+
.PP
|
2820
|
+
You need the following files in your source tree, or in a directory
|
2821
|
+
in your include path (e.g. in libev/ when using \-Ilibev):
|
2822
|
+
.PP
|
2823
|
+
.Vb 4
|
2824
|
+
\& ev.h
|
2825
|
+
\& ev.c
|
2826
|
+
\& ev_vars.h
|
2827
|
+
\& ev_wrap.h
|
2828
|
+
\&
|
2829
|
+
\& ev_win32.c required on win32 platforms only
|
2830
|
+
\&
|
2831
|
+
\& ev_select.c only when select backend is enabled (which is enabled by default)
|
2832
|
+
\& ev_poll.c only when poll backend is enabled (disabled by default)
|
2833
|
+
\& ev_epoll.c only when the epoll backend is enabled (disabled by default)
|
2834
|
+
\& ev_kqueue.c only when the kqueue backend is enabled (disabled by default)
|
2835
|
+
\& ev_port.c only when the solaris port backend is enabled (disabled by default)
|
2836
|
+
.Ve
|
2837
|
+
.PP
|
2838
|
+
\&\fIev.c\fR includes the backend files directly when enabled, so you only need
|
2839
|
+
to compile this single file.
|
2840
|
+
.PP
|
2841
|
+
\fI\s-1LIBEVENT\s0 \s-1COMPATIBILITY\s0 \s-1API\s0\fR
|
2842
|
+
.IX Subsection "LIBEVENT COMPATIBILITY API"
|
2843
|
+
.PP
|
2844
|
+
To include the libevent compatibility \s-1API\s0, also include:
|
2845
|
+
.PP
|
2846
|
+
.Vb 1
|
2847
|
+
\& #include "event.c"
|
2848
|
+
.Ve
|
2849
|
+
.PP
|
2850
|
+
in the file including \fIev.c\fR, and:
|
2851
|
+
.PP
|
2852
|
+
.Vb 1
|
2853
|
+
\& #include "event.h"
|
2854
|
+
.Ve
|
2855
|
+
.PP
|
2856
|
+
in the files that want to use the libevent \s-1API\s0. This also includes \fIev.h\fR.
|
2857
|
+
.PP
|
2858
|
+
You need the following additional files for this:
|
2859
|
+
.PP
|
2860
|
+
.Vb 2
|
2861
|
+
\& event.h
|
2862
|
+
\& event.c
|
2863
|
+
.Ve
|
2864
|
+
.PP
|
2865
|
+
\fI\s-1AUTOCONF\s0 \s-1SUPPORT\s0\fR
|
2866
|
+
.IX Subsection "AUTOCONF SUPPORT"
|
2867
|
+
.PP
|
2868
|
+
Instead of using \f(CW\*(C`EV_STANDALONE=1\*(C'\fR and providing your config in
|
2869
|
+
whatever way you want, you can also \f(CW\*(C`m4_include([libev.m4])\*(C'\fR in your
|
2870
|
+
\&\fIconfigure.ac\fR and leave \f(CW\*(C`EV_STANDALONE\*(C'\fR undefined. \fIev.c\fR will then
|
2871
|
+
include \fIconfig.h\fR and configure itself accordingly.
|
2872
|
+
.PP
|
2873
|
+
For this of course you need the m4 file:
|
2874
|
+
.PP
|
2875
|
+
.Vb 1
|
2876
|
+
\& libev.m4
|
2877
|
+
.Ve
|
2878
|
+
.Sh "\s-1PREPROCESSOR\s0 \s-1SYMBOLS/MACROS\s0"
|
2879
|
+
.IX Subsection "PREPROCESSOR SYMBOLS/MACROS"
|
2880
|
+
Libev can be configured via a variety of preprocessor symbols you have to
|
2881
|
+
define before including any of its files. The default in the absense of
|
2882
|
+
autoconf is noted for every option.
|
2883
|
+
.IP "\s-1EV_STANDALONE\s0" 4
|
2884
|
+
.IX Item "EV_STANDALONE"
|
2885
|
+
Must always be \f(CW1\fR if you do not use autoconf configuration, which
|
2886
|
+
keeps libev from including \fIconfig.h\fR, and it also defines dummy
|
2887
|
+
implementations for some libevent functions (such as logging, which is not
|
2888
|
+
supported). It will also not define any of the structs usually found in
|
2889
|
+
\&\fIevent.h\fR that are not directly supported by the libev core alone.
|
2890
|
+
.IP "\s-1EV_USE_MONOTONIC\s0" 4
|
2891
|
+
.IX Item "EV_USE_MONOTONIC"
|
2892
|
+
If defined to be \f(CW1\fR, libev will try to detect the availability of the
|
2893
|
+
monotonic clock option at both compiletime and runtime. Otherwise no use
|
2894
|
+
of the monotonic clock option will be attempted. If you enable this, you
|
2895
|
+
usually have to link against librt or something similar. Enabling it when
|
2896
|
+
the functionality isn't available is safe, though, although you have
|
2897
|
+
to make sure you link against any libraries where the \f(CW\*(C`clock_gettime\*(C'\fR
|
2898
|
+
function is hiding in (often \fI\-lrt\fR).
|
2899
|
+
.IP "\s-1EV_USE_REALTIME\s0" 4
|
2900
|
+
.IX Item "EV_USE_REALTIME"
|
2901
|
+
If defined to be \f(CW1\fR, libev will try to detect the availability of the
|
2902
|
+
realtime clock option at compiletime (and assume its availability at
|
2903
|
+
runtime if successful). Otherwise no use of the realtime clock option will
|
2904
|
+
be attempted. This effectively replaces \f(CW\*(C`gettimeofday\*(C'\fR by \f(CW\*(C`clock_get
|
2905
|
+
(CLOCK_REALTIME, ...)\*(C'\fR and will not normally affect correctness. See the
|
2906
|
+
note about libraries in the description of \f(CW\*(C`EV_USE_MONOTONIC\*(C'\fR, though.
|
2907
|
+
.IP "\s-1EV_USE_NANOSLEEP\s0" 4
|
2908
|
+
.IX Item "EV_USE_NANOSLEEP"
|
2909
|
+
If defined to be \f(CW1\fR, libev will assume that \f(CW\*(C`nanosleep ()\*(C'\fR is available
|
2910
|
+
and will use it for delays. Otherwise it will use \f(CW\*(C`select ()\*(C'\fR.
|
2911
|
+
.IP "\s-1EV_USE_EVENTFD\s0" 4
|
2912
|
+
.IX Item "EV_USE_EVENTFD"
|
2913
|
+
If defined to be \f(CW1\fR, then libev will assume that \f(CW\*(C`eventfd ()\*(C'\fR is
|
2914
|
+
available and will probe for kernel support at runtime. This will improve
|
2915
|
+
\&\f(CW\*(C`ev_signal\*(C'\fR and \f(CW\*(C`ev_async\*(C'\fR performance and reduce resource consumption.
|
2916
|
+
If undefined, it will be enabled if the headers indicate GNU/Linux + Glibc
|
2917
|
+
2.7 or newer, otherwise disabled.
|
2918
|
+
.IP "\s-1EV_USE_SELECT\s0" 4
|
2919
|
+
.IX Item "EV_USE_SELECT"
|
2920
|
+
If undefined or defined to be \f(CW1\fR, libev will compile in support for the
|
2921
|
+
\&\f(CW\*(C`select\*(C'\fR(2) backend. No attempt at autodetection will be done: if no
|
2922
|
+
other method takes over, select will be it. Otherwise the select backend
|
2923
|
+
will not be compiled in.
|
2924
|
+
.IP "\s-1EV_SELECT_USE_FD_SET\s0" 4
|
2925
|
+
.IX Item "EV_SELECT_USE_FD_SET"
|
2926
|
+
If defined to \f(CW1\fR, then the select backend will use the system \f(CW\*(C`fd_set\*(C'\fR
|
2927
|
+
structure. This is useful if libev doesn't compile due to a missing
|
2928
|
+
\&\f(CW\*(C`NFDBITS\*(C'\fR or \f(CW\*(C`fd_mask\*(C'\fR definition or it misguesses the bitset layout on
|
2929
|
+
exotic systems. This usually limits the range of file descriptors to some
|
2930
|
+
low limit such as 1024 or might have other limitations (winsocket only
|
2931
|
+
allows 64 sockets). The \f(CW\*(C`FD_SETSIZE\*(C'\fR macro, set before compilation, might
|
2932
|
+
influence the size of the \f(CW\*(C`fd_set\*(C'\fR used.
|
2933
|
+
.IP "\s-1EV_SELECT_IS_WINSOCKET\s0" 4
|
2934
|
+
.IX Item "EV_SELECT_IS_WINSOCKET"
|
2935
|
+
When defined to \f(CW1\fR, the select backend will assume that
|
2936
|
+
select/socket/connect etc. don't understand file descriptors but
|
2937
|
+
wants osf handles on win32 (this is the case when the select to
|
2938
|
+
be used is the winsock select). This means that it will call
|
2939
|
+
\&\f(CW\*(C`_get_osfhandle\*(C'\fR on the fd to convert it to an \s-1OS\s0 handle. Otherwise,
|
2940
|
+
it is assumed that all these functions actually work on fds, even
|
2941
|
+
on win32. Should not be defined on non\-win32 platforms.
|
2942
|
+
.IP "\s-1EV_FD_TO_WIN32_HANDLE\s0" 4
|
2943
|
+
.IX Item "EV_FD_TO_WIN32_HANDLE"
|
2944
|
+
If \f(CW\*(C`EV_SELECT_IS_WINSOCKET\*(C'\fR is enabled, then libev needs a way to map
|
2945
|
+
file descriptors to socket handles. When not defining this symbol (the
|
2946
|
+
default), then libev will call \f(CW\*(C`_get_osfhandle\*(C'\fR, which is usually
|
2947
|
+
correct. In some cases, programs use their own file descriptor management,
|
2948
|
+
in which case they can provide this function to map fds to socket handles.
|
2949
|
+
.IP "\s-1EV_USE_POLL\s0" 4
|
2950
|
+
.IX Item "EV_USE_POLL"
|
2951
|
+
If defined to be \f(CW1\fR, libev will compile in support for the \f(CW\*(C`poll\*(C'\fR(2)
|
2952
|
+
backend. Otherwise it will be enabled on non\-win32 platforms. It
|
2953
|
+
takes precedence over select.
|
2954
|
+
.IP "\s-1EV_USE_EPOLL\s0" 4
|
2955
|
+
.IX Item "EV_USE_EPOLL"
|
2956
|
+
If defined to be \f(CW1\fR, libev will compile in support for the Linux
|
2957
|
+
\&\f(CW\*(C`epoll\*(C'\fR(7) backend. Its availability will be detected at runtime,
|
2958
|
+
otherwise another method will be used as fallback. This is the preferred
|
2959
|
+
backend for GNU/Linux systems. If undefined, it will be enabled if the
|
2960
|
+
headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
|
2961
|
+
.IP "\s-1EV_USE_KQUEUE\s0" 4
|
2962
|
+
.IX Item "EV_USE_KQUEUE"
|
2963
|
+
If defined to be \f(CW1\fR, libev will compile in support for the \s-1BSD\s0 style
|
2964
|
+
\&\f(CW\*(C`kqueue\*(C'\fR(2) backend. Its actual availability will be detected at runtime,
|
2965
|
+
otherwise another method will be used as fallback. This is the preferred
|
2966
|
+
backend for \s-1BSD\s0 and BSD-like systems, although on most BSDs kqueue only
|
2967
|
+
supports some types of fds correctly (the only platform we found that
|
2968
|
+
supports ptys for example was NetBSD), so kqueue might be compiled in, but
|
2969
|
+
not be used unless explicitly requested. The best way to use it is to find
|
2970
|
+
out whether kqueue supports your type of fd properly and use an embedded
|
2971
|
+
kqueue loop.
|
2972
|
+
.IP "\s-1EV_USE_PORT\s0" 4
|
2973
|
+
.IX Item "EV_USE_PORT"
|
2974
|
+
If defined to be \f(CW1\fR, libev will compile in support for the Solaris
|
2975
|
+
10 port style backend. Its availability will be detected at runtime,
|
2976
|
+
otherwise another method will be used as fallback. This is the preferred
|
2977
|
+
backend for Solaris 10 systems.
|
2978
|
+
.IP "\s-1EV_USE_DEVPOLL\s0" 4
|
2979
|
+
.IX Item "EV_USE_DEVPOLL"
|
2980
|
+
reserved for future expansion, works like the \s-1USE\s0 symbols above.
|
2981
|
+
.IP "\s-1EV_USE_INOTIFY\s0" 4
|
2982
|
+
.IX Item "EV_USE_INOTIFY"
|
2983
|
+
If defined to be \f(CW1\fR, libev will compile in support for the Linux inotify
|
2984
|
+
interface to speed up \f(CW\*(C`ev_stat\*(C'\fR watchers. Its actual availability will
|
2985
|
+
be detected at runtime. If undefined, it will be enabled if the headers
|
2986
|
+
indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
|
2987
|
+
.IP "\s-1EV_ATOMIC_T\s0" 4
|
2988
|
+
.IX Item "EV_ATOMIC_T"
|
2989
|
+
Libev requires an integer type (suitable for storing \f(CW0\fR or \f(CW1\fR) whose
|
2990
|
+
access is atomic with respect to other threads or signal contexts. No such
|
2991
|
+
type is easily found in the C language, so you can provide your own type
|
2992
|
+
that you know is safe for your purposes. It is used both for signal handler \*(L"locking\*(R"
|
2993
|
+
as well as for signal and thread safety in \f(CW\*(C`ev_async\*(C'\fR watchers.
|
2994
|
+
.Sp
|
2995
|
+
In the absense of this define, libev will use \f(CW\*(C`sig_atomic_t volatile\*(C'\fR
|
2996
|
+
(from \fIsignal.h\fR), which is usually good enough on most platforms.
|
2997
|
+
.IP "\s-1EV_H\s0" 4
|
2998
|
+
.IX Item "EV_H"
|
2999
|
+
The name of the \fIev.h\fR header file used to include it. The default if
|
3000
|
+
undefined is \f(CW"ev.h"\fR in \fIevent.h\fR, \fIev.c\fR and \fIev++.h\fR. This can be
|
3001
|
+
used to virtually rename the \fIev.h\fR header file in case of conflicts.
|
3002
|
+
.IP "\s-1EV_CONFIG_H\s0" 4
|
3003
|
+
.IX Item "EV_CONFIG_H"
|
3004
|
+
If \f(CW\*(C`EV_STANDALONE\*(C'\fR isn't \f(CW1\fR, this variable can be used to override
|
3005
|
+
\&\fIev.c\fR's idea of where to find the \fIconfig.h\fR file, similarly to
|
3006
|
+
\&\f(CW\*(C`EV_H\*(C'\fR, above.
|
3007
|
+
.IP "\s-1EV_EVENT_H\s0" 4
|
3008
|
+
.IX Item "EV_EVENT_H"
|
3009
|
+
Similarly to \f(CW\*(C`EV_H\*(C'\fR, this macro can be used to override \fIevent.c\fR's idea
|
3010
|
+
of how the \fIevent.h\fR header can be found, the default is \f(CW"event.h"\fR.
|
3011
|
+
.IP "\s-1EV_PROTOTYPES\s0" 4
|
3012
|
+
.IX Item "EV_PROTOTYPES"
|
3013
|
+
If defined to be \f(CW0\fR, then \fIev.h\fR will not define any function
|
3014
|
+
prototypes, but still define all the structs and other symbols. This is
|
3015
|
+
occasionally useful if you want to provide your own wrapper functions
|
3016
|
+
around libev functions.
|
3017
|
+
.IP "\s-1EV_MULTIPLICITY\s0" 4
|
3018
|
+
.IX Item "EV_MULTIPLICITY"
|
3019
|
+
If undefined or defined to \f(CW1\fR, then all event-loop-specific functions
|
3020
|
+
will have the \f(CW\*(C`struct ev_loop *\*(C'\fR as first argument, and you can create
|
3021
|
+
additional independent event loops. Otherwise there will be no support
|
3022
|
+
for multiple event loops and there is no first event loop pointer
|
3023
|
+
argument. Instead, all functions act on the single default loop.
|
3024
|
+
.IP "\s-1EV_MINPRI\s0" 4
|
3025
|
+
.IX Item "EV_MINPRI"
|
3026
|
+
.PD 0
|
3027
|
+
.IP "\s-1EV_MAXPRI\s0" 4
|
3028
|
+
.IX Item "EV_MAXPRI"
|
3029
|
+
.PD
|
3030
|
+
The range of allowed priorities. \f(CW\*(C`EV_MINPRI\*(C'\fR must be smaller or equal to
|
3031
|
+
\&\f(CW\*(C`EV_MAXPRI\*(C'\fR, but otherwise there are no non-obvious limitations. You can
|
3032
|
+
provide for more priorities by overriding those symbols (usually defined
|
3033
|
+
to be \f(CW\*(C`\-2\*(C'\fR and \f(CW2\fR, respectively).
|
3034
|
+
.Sp
|
3035
|
+
When doing priority-based operations, libev usually has to linearly search
|
3036
|
+
all the priorities, so having many of them (hundreds) uses a lot of space
|
3037
|
+
and time, so using the defaults of five priorities (\-2 .. +2) is usually
|
3038
|
+
fine.
|
3039
|
+
.Sp
|
3040
|
+
If your embedding app does not need any priorities, defining these both to
|
3041
|
+
\&\f(CW0\fR will save some memory and cpu.
|
3042
|
+
.IP "\s-1EV_PERIODIC_ENABLE\s0" 4
|
3043
|
+
.IX Item "EV_PERIODIC_ENABLE"
|
3044
|
+
If undefined or defined to be \f(CW1\fR, then periodic timers are supported. If
|
3045
|
+
defined to be \f(CW0\fR, then they are not. Disabling them saves a few kB of
|
3046
|
+
code.
|
3047
|
+
.IP "\s-1EV_IDLE_ENABLE\s0" 4
|
3048
|
+
.IX Item "EV_IDLE_ENABLE"
|
3049
|
+
If undefined or defined to be \f(CW1\fR, then idle watchers are supported. If
|
3050
|
+
defined to be \f(CW0\fR, then they are not. Disabling them saves a few kB of
|
3051
|
+
code.
|
3052
|
+
.IP "\s-1EV_EMBED_ENABLE\s0" 4
|
3053
|
+
.IX Item "EV_EMBED_ENABLE"
|
3054
|
+
If undefined or defined to be \f(CW1\fR, then embed watchers are supported. If
|
3055
|
+
defined to be \f(CW0\fR, then they are not.
|
3056
|
+
.IP "\s-1EV_STAT_ENABLE\s0" 4
|
3057
|
+
.IX Item "EV_STAT_ENABLE"
|
3058
|
+
If undefined or defined to be \f(CW1\fR, then stat watchers are supported. If
|
3059
|
+
defined to be \f(CW0\fR, then they are not.
|
3060
|
+
.IP "\s-1EV_FORK_ENABLE\s0" 4
|
3061
|
+
.IX Item "EV_FORK_ENABLE"
|
3062
|
+
If undefined or defined to be \f(CW1\fR, then fork watchers are supported. If
|
3063
|
+
defined to be \f(CW0\fR, then they are not.
|
3064
|
+
.IP "\s-1EV_ASYNC_ENABLE\s0" 4
|
3065
|
+
.IX Item "EV_ASYNC_ENABLE"
|
3066
|
+
If undefined or defined to be \f(CW1\fR, then async watchers are supported. If
|
3067
|
+
defined to be \f(CW0\fR, then they are not.
|
3068
|
+
.IP "\s-1EV_MINIMAL\s0" 4
|
3069
|
+
.IX Item "EV_MINIMAL"
|
3070
|
+
If you need to shave off some kilobytes of code at the expense of some
|
3071
|
+
speed, define this symbol to \f(CW1\fR. Currently this is used to override some
|
3072
|
+
inlining decisions, saves roughly 30% codesize of amd64. It also selects a
|
3073
|
+
much smaller 2\-heap for timer management over the default 4\-heap.
|
3074
|
+
.IP "\s-1EV_PID_HASHSIZE\s0" 4
|
3075
|
+
.IX Item "EV_PID_HASHSIZE"
|
3076
|
+
\&\f(CW\*(C`ev_child\*(C'\fR watchers use a small hash table to distribute workload by
|
3077
|
+
pid. The default size is \f(CW16\fR (or \f(CW1\fR with \f(CW\*(C`EV_MINIMAL\*(C'\fR), usually more
|
3078
|
+
than enough. If you need to manage thousands of children you might want to
|
3079
|
+
increase this value (\fImust\fR be a power of two).
|
3080
|
+
.IP "\s-1EV_INOTIFY_HASHSIZE\s0" 4
|
3081
|
+
.IX Item "EV_INOTIFY_HASHSIZE"
|
3082
|
+
\&\f(CW\*(C`ev_stat\*(C'\fR watchers use a small hash table to distribute workload by
|
3083
|
+
inotify watch id. The default size is \f(CW16\fR (or \f(CW1\fR with \f(CW\*(C`EV_MINIMAL\*(C'\fR),
|
3084
|
+
usually more than enough. If you need to manage thousands of \f(CW\*(C`ev_stat\*(C'\fR
|
3085
|
+
watchers you might want to increase this value (\fImust\fR be a power of
|
3086
|
+
two).
|
3087
|
+
.IP "\s-1EV_USE_4HEAP\s0" 4
|
3088
|
+
.IX Item "EV_USE_4HEAP"
|
3089
|
+
Heaps are not very cache-efficient. To improve the cache-efficiency of the
|
3090
|
+
timer and periodics heap, libev uses a 4\-heap when this symbol is defined
|
3091
|
+
to \f(CW1\fR. The 4\-heap uses more complicated (longer) code but has a
|
3092
|
+
noticable after performance with many (thousands) of watchers.
|
3093
|
+
.Sp
|
3094
|
+
The default is \f(CW1\fR unless \f(CW\*(C`EV_MINIMAL\*(C'\fR is set in which case it is \f(CW0\fR
|
3095
|
+
(disabled).
|
3096
|
+
.IP "\s-1EV_HEAP_CACHE_AT\s0" 4
|
3097
|
+
.IX Item "EV_HEAP_CACHE_AT"
|
3098
|
+
Heaps are not very cache-efficient. To improve the cache-efficiency of the
|
3099
|
+
timer and periodics heap, libev can cache the timestamp (\fIat\fR) within
|
3100
|
+
the heap structure (selected by defining \f(CW\*(C`EV_HEAP_CACHE_AT\*(C'\fR to \f(CW1\fR),
|
3101
|
+
which uses 8\-12 bytes more per watcher and a few hundred bytes more code,
|
3102
|
+
but avoids random read accesses on heap changes. This noticably improves
|
3103
|
+
performance noticably with with many (hundreds) of watchers.
|
3104
|
+
.Sp
|
3105
|
+
The default is \f(CW1\fR unless \f(CW\*(C`EV_MINIMAL\*(C'\fR is set in which case it is \f(CW0\fR
|
3106
|
+
(disabled).
|
3107
|
+
.IP "\s-1EV_COMMON\s0" 4
|
3108
|
+
.IX Item "EV_COMMON"
|
3109
|
+
By default, all watchers have a \f(CW\*(C`void *data\*(C'\fR member. By redefining
|
3110
|
+
this macro to a something else you can include more and other types of
|
3111
|
+
members. You have to define it each time you include one of the files,
|
3112
|
+
though, and it must be identical each time.
|
3113
|
+
.Sp
|
3114
|
+
For example, the perl \s-1EV\s0 module uses something like this:
|
3115
|
+
.Sp
|
3116
|
+
.Vb 3
|
3117
|
+
\& #define EV_COMMON \e
|
3118
|
+
\& SV *self; /* contains this struct */ \e
|
3119
|
+
\& SV *cb_sv, *fh /* note no trailing ";" */
|
3120
|
+
.Ve
|
3121
|
+
.IP "\s-1EV_CB_DECLARE\s0 (type)" 4
|
3122
|
+
.IX Item "EV_CB_DECLARE (type)"
|
3123
|
+
.PD 0
|
3124
|
+
.IP "\s-1EV_CB_INVOKE\s0 (watcher, revents)" 4
|
3125
|
+
.IX Item "EV_CB_INVOKE (watcher, revents)"
|
3126
|
+
.IP "ev_set_cb (ev, cb)" 4
|
3127
|
+
.IX Item "ev_set_cb (ev, cb)"
|
3128
|
+
.PD
|
3129
|
+
Can be used to change the callback member declaration in each watcher,
|
3130
|
+
and the way callbacks are invoked and set. Must expand to a struct member
|
3131
|
+
definition and a statement, respectively. See the \fIev.h\fR header file for
|
3132
|
+
their default definitions. One possible use for overriding these is to
|
3133
|
+
avoid the \f(CW\*(C`struct ev_loop *\*(C'\fR as first argument in all cases, or to use
|
3134
|
+
method calls instead of plain function calls in \*(C+.
|
3135
|
+
.Sh "\s-1EXPORTED\s0 \s-1API\s0 \s-1SYMBOLS\s0"
|
3136
|
+
.IX Subsection "EXPORTED API SYMBOLS"
|
3137
|
+
If you need to re-export the \s-1API\s0 (e.g. via a dll) and you need a list of
|
3138
|
+
exported symbols, you can use the provided \fISymbol.*\fR files which list
|
3139
|
+
all public symbols, one per line:
|
3140
|
+
.PP
|
3141
|
+
.Vb 2
|
3142
|
+
\& Symbols.ev for libev proper
|
3143
|
+
\& Symbols.event for the libevent emulation
|
3144
|
+
.Ve
|
3145
|
+
.PP
|
3146
|
+
This can also be used to rename all public symbols to avoid clashes with
|
3147
|
+
multiple versions of libev linked together (which is obviously bad in
|
3148
|
+
itself, but sometimes it is inconvinient to avoid this).
|
3149
|
+
.PP
|
3150
|
+
A sed command like this will create wrapper \f(CW\*(C`#define\*(C'\fR's that you need to
|
3151
|
+
include before including \fIev.h\fR:
|
3152
|
+
.PP
|
3153
|
+
.Vb 1
|
3154
|
+
\& <Symbols.ev sed \-e "s/.*/#define & myprefix_&/" >wrap.h
|
3155
|
+
.Ve
|
3156
|
+
.PP
|
3157
|
+
This would create a file \fIwrap.h\fR which essentially looks like this:
|
3158
|
+
.PP
|
3159
|
+
.Vb 4
|
3160
|
+
\& #define ev_backend myprefix_ev_backend
|
3161
|
+
\& #define ev_check_start myprefix_ev_check_start
|
3162
|
+
\& #define ev_check_stop myprefix_ev_check_stop
|
3163
|
+
\& ...
|
3164
|
+
.Ve
|
3165
|
+
.Sh "\s-1EXAMPLES\s0"
|
3166
|
+
.IX Subsection "EXAMPLES"
|
3167
|
+
For a real-world example of a program the includes libev
|
3168
|
+
verbatim, you can have a look at the \s-1EV\s0 perl module
|
3169
|
+
(<http://software.schmorp.de/pkg/EV.html>). It has the libev files in
|
3170
|
+
the \fIlibev/\fR subdirectory and includes them in the \fI\s-1EV/EVAPI\s0.h\fR (public
|
3171
|
+
interface) and \fI\s-1EV\s0.xs\fR (implementation) files. Only the \fI\s-1EV\s0.xs\fR file
|
3172
|
+
will be compiled. It is pretty complex because it provides its own header
|
3173
|
+
file.
|
3174
|
+
.PP
|
3175
|
+
The usage in rxvt-unicode is simpler. It has a \fIev_cpp.h\fR header file
|
3176
|
+
that everybody includes and which overrides some configure choices:
|
3177
|
+
.PP
|
3178
|
+
.Vb 9
|
3179
|
+
\& #define EV_MINIMAL 1
|
3180
|
+
\& #define EV_USE_POLL 0
|
3181
|
+
\& #define EV_MULTIPLICITY 0
|
3182
|
+
\& #define EV_PERIODIC_ENABLE 0
|
3183
|
+
\& #define EV_STAT_ENABLE 0
|
3184
|
+
\& #define EV_FORK_ENABLE 0
|
3185
|
+
\& #define EV_CONFIG_H <config.h>
|
3186
|
+
\& #define EV_MINPRI 0
|
3187
|
+
\& #define EV_MAXPRI 0
|
3188
|
+
\&
|
3189
|
+
\& #include "ev++.h"
|
3190
|
+
.Ve
|
3191
|
+
.PP
|
3192
|
+
And a \fIev_cpp.C\fR implementation file that contains libev proper and is compiled:
|
3193
|
+
.PP
|
3194
|
+
.Vb 2
|
3195
|
+
\& #include "ev_cpp.h"
|
3196
|
+
\& #include "ev.c"
|
3197
|
+
.Ve
|
3198
|
+
.SH "THREADS AND COROUTINES"
|
3199
|
+
.IX Header "THREADS AND COROUTINES"
|
3200
|
+
.Sh "\s-1THREADS\s0"
|
3201
|
+
.IX Subsection "THREADS"
|
3202
|
+
Libev itself is completely threadsafe, but it uses no locking. This
|
3203
|
+
means that you can use as many loops as you want in parallel, as long as
|
3204
|
+
only one thread ever calls into one libev function with the same loop
|
3205
|
+
parameter.
|
3206
|
+
.PP
|
3207
|
+
Or put differently: calls with different loop parameters can be done in
|
3208
|
+
parallel from multiple threads, calls with the same loop parameter must be
|
3209
|
+
done serially (but can be done from different threads, as long as only one
|
3210
|
+
thread ever is inside a call at any point in time, e.g. by using a mutex
|
3211
|
+
per loop).
|
3212
|
+
.PP
|
3213
|
+
If you want to know which design is best for your problem, then I cannot
|
3214
|
+
help you but by giving some generic advice:
|
3215
|
+
.IP "\(bu" 4
|
3216
|
+
most applications have a main thread: use the default libev loop
|
3217
|
+
in that thread, or create a seperate thread running only the default loop.
|
3218
|
+
.Sp
|
3219
|
+
This helps integrating other libraries or software modules that use libev
|
3220
|
+
themselves and don't care/know about threading.
|
3221
|
+
.IP "\(bu" 4
|
3222
|
+
one loop per thread is usually a good model.
|
3223
|
+
.Sp
|
3224
|
+
Doing this is almost never wrong, sometimes a better-performance model
|
3225
|
+
exists, but it is always a good start.
|
3226
|
+
.IP "\(bu" 4
|
3227
|
+
other models exist, such as the leader/follower pattern, where one
|
3228
|
+
loop is handed through multiple threads in a kind of round-robbin fashion.
|
3229
|
+
.Sp
|
3230
|
+
Chosing a model is hard \- look around, learn, know that usually you cna do
|
3231
|
+
better than you currently do :\-)
|
3232
|
+
.IP "\(bu" 4
|
3233
|
+
often you need to talk to some other thread which blocks in the
|
3234
|
+
event loop \- \f(CW\*(C`ev_async\*(C'\fR watchers can be used to wake them up from other
|
3235
|
+
threads safely (or from signal contexts...).
|
3236
|
+
.Sh "\s-1COROUTINES\s0"
|
3237
|
+
.IX Subsection "COROUTINES"
|
3238
|
+
Libev is much more accomodating to coroutines (\*(L"cooperative threads\*(R"):
|
3239
|
+
libev fully supports nesting calls to it's functions from different
|
3240
|
+
coroutines (e.g. you can call \f(CW\*(C`ev_loop\*(C'\fR on the same loop from two
|
3241
|
+
different coroutines and switch freely between both coroutines running the
|
3242
|
+
loop, as long as you don't confuse yourself). The only exception is that
|
3243
|
+
you must not do this from \f(CW\*(C`ev_periodic\*(C'\fR reschedule callbacks.
|
3244
|
+
.PP
|
3245
|
+
Care has been invested into making sure that libev does not keep local
|
3246
|
+
state inside \f(CW\*(C`ev_loop\*(C'\fR, and other calls do not usually allow coroutine
|
3247
|
+
switches.
|
3248
|
+
.SH "COMPLEXITIES"
|
3249
|
+
.IX Header "COMPLEXITIES"
|
3250
|
+
In this section the complexities of (many of) the algorithms used inside
|
3251
|
+
libev will be explained. For complexity discussions about backends see the
|
3252
|
+
documentation for \f(CW\*(C`ev_default_init\*(C'\fR.
|
3253
|
+
.PP
|
3254
|
+
All of the following are about amortised time: If an array needs to be
|
3255
|
+
extended, libev needs to realloc and move the whole array, but this
|
3256
|
+
happens asymptotically never with higher number of elements, so O(1) might
|
3257
|
+
mean it might do a lengthy realloc operation in rare cases, but on average
|
3258
|
+
it is much faster and asymptotically approaches constant time.
|
3259
|
+
.IP "Starting and stopping timer/periodic watchers: O(log skipped_other_timers)" 4
|
3260
|
+
.IX Item "Starting and stopping timer/periodic watchers: O(log skipped_other_timers)"
|
3261
|
+
This means that, when you have a watcher that triggers in one hour and
|
3262
|
+
there are 100 watchers that would trigger before that then inserting will
|
3263
|
+
have to skip roughly seven (\f(CW\*(C`ld 100\*(C'\fR) of these watchers.
|
3264
|
+
.IP "Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers)" 4
|
3265
|
+
.IX Item "Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers)"
|
3266
|
+
That means that changing a timer costs less than removing/adding them
|
3267
|
+
as only the relative motion in the event queue has to be paid for.
|
3268
|
+
.IP "Starting io/check/prepare/idle/signal/child/fork/async watchers: O(1)" 4
|
3269
|
+
.IX Item "Starting io/check/prepare/idle/signal/child/fork/async watchers: O(1)"
|
3270
|
+
These just add the watcher into an array or at the head of a list.
|
3271
|
+
.IP "Stopping check/prepare/idle/fork/async watchers: O(1)" 4
|
3272
|
+
.IX Item "Stopping check/prepare/idle/fork/async watchers: O(1)"
|
3273
|
+
.PD 0
|
3274
|
+
.IP "Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % \s-1EV_PID_HASHSIZE\s0))" 4
|
3275
|
+
.IX Item "Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HASHSIZE))"
|
3276
|
+
.PD
|
3277
|
+
These watchers are stored in lists then need to be walked to find the
|
3278
|
+
correct watcher to remove. The lists are usually short (you don't usually
|
3279
|
+
have many watchers waiting for the same fd or signal).
|
3280
|
+
.IP "Finding the next timer in each loop iteration: O(1)" 4
|
3281
|
+
.IX Item "Finding the next timer in each loop iteration: O(1)"
|
3282
|
+
By virtue of using a binary or 4\-heap, the next timer is always found at a
|
3283
|
+
fixed position in the storage array.
|
3284
|
+
.IP "Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)" 4
|
3285
|
+
.IX Item "Each change on a file descriptor per loop iteration: O(number_of_watchers_for_this_fd)"
|
3286
|
+
A change means an I/O watcher gets started or stopped, which requires
|
3287
|
+
libev to recalculate its status (and possibly tell the kernel, depending
|
3288
|
+
on backend and wether \f(CW\*(C`ev_io_set\*(C'\fR was used).
|
3289
|
+
.IP "Activating one watcher (putting it into the pending state): O(1)" 4
|
3290
|
+
.IX Item "Activating one watcher (putting it into the pending state): O(1)"
|
3291
|
+
.PD 0
|
3292
|
+
.IP "Priority handling: O(number_of_priorities)" 4
|
3293
|
+
.IX Item "Priority handling: O(number_of_priorities)"
|
3294
|
+
.PD
|
3295
|
+
Priorities are implemented by allocating some space for each
|
3296
|
+
priority. When doing priority-based operations, libev usually has to
|
3297
|
+
linearly search all the priorities, but starting/stopping and activating
|
3298
|
+
watchers becomes O(1) w.r.t. priority handling.
|
3299
|
+
.IP "Sending an ev_async: O(1)" 4
|
3300
|
+
.IX Item "Sending an ev_async: O(1)"
|
3301
|
+
.PD 0
|
3302
|
+
.IP "Processing ev_async_send: O(number_of_async_watchers)" 4
|
3303
|
+
.IX Item "Processing ev_async_send: O(number_of_async_watchers)"
|
3304
|
+
.IP "Processing signals: O(max_signal_number)" 4
|
3305
|
+
.IX Item "Processing signals: O(max_signal_number)"
|
3306
|
+
.PD
|
3307
|
+
Sending involves a syscall \fIiff\fR there were no other \f(CW\*(C`ev_async_send\*(C'\fR
|
3308
|
+
calls in the current loop iteration. Checking for async and signal events
|
3309
|
+
involves iterating over all running async watchers or all signal numbers.
|
3310
|
+
.SH "Win32 platform limitations and workarounds"
|
3311
|
+
.IX Header "Win32 platform limitations and workarounds"
|
3312
|
+
Win32 doesn't support any of the standards (e.g. \s-1POSIX\s0) that libev
|
3313
|
+
requires, and its I/O model is fundamentally incompatible with the \s-1POSIX\s0
|
3314
|
+
model. Libev still offers limited functionality on this platform in
|
3315
|
+
the form of the \f(CW\*(C`EVBACKEND_SELECT\*(C'\fR backend, and only supports socket
|
3316
|
+
descriptors. This only applies when using Win32 natively, not when using
|
3317
|
+
e.g. cygwin.
|
3318
|
+
.PP
|
3319
|
+
Lifting these limitations would basically require the full
|
3320
|
+
re-implementation of the I/O system. If you are into these kinds of
|
3321
|
+
things, then note that glib does exactly that for you in a very portable
|
3322
|
+
way (note also that glib is the slowest event library known to man).
|
3323
|
+
.PP
|
3324
|
+
There is no supported compilation method available on windows except
|
3325
|
+
embedding it into other applications.
|
3326
|
+
.PP
|
3327
|
+
Due to the many, low, and arbitrary limits on the win32 platform and
|
3328
|
+
the abysmal performance of winsockets, using a large number of sockets
|
3329
|
+
is not recommended (and not reasonable). If your program needs to use
|
3330
|
+
more than a hundred or so sockets, then likely it needs to use a totally
|
3331
|
+
different implementation for windows, as libev offers the \s-1POSIX\s0 readyness
|
3332
|
+
notification model, which cannot be implemented efficiently on windows
|
3333
|
+
(microsoft monopoly games).
|
3334
|
+
.IP "The winsocket select function" 4
|
3335
|
+
.IX Item "The winsocket select function"
|
3336
|
+
The winsocket \f(CW\*(C`select\*(C'\fR function doesn't follow \s-1POSIX\s0 in that it requires
|
3337
|
+
socket \fIhandles\fR and not socket \fIfile descriptors\fR. This makes select
|
3338
|
+
very inefficient, and also requires a mapping from file descriptors
|
3339
|
+
to socket handles. See the discussion of the \f(CW\*(C`EV_SELECT_USE_FD_SET\*(C'\fR,
|
3340
|
+
\&\f(CW\*(C`EV_SELECT_IS_WINSOCKET\*(C'\fR and \f(CW\*(C`EV_FD_TO_WIN32_HANDLE\*(C'\fR preprocessor
|
3341
|
+
symbols for more info.
|
3342
|
+
.Sp
|
3343
|
+
The configuration for a \*(L"naked\*(R" win32 using the microsoft runtime
|
3344
|
+
libraries and raw winsocket select is:
|
3345
|
+
.Sp
|
3346
|
+
.Vb 2
|
3347
|
+
\& #define EV_USE_SELECT 1
|
3348
|
+
\& #define EV_SELECT_IS_WINSOCKET 1 /* forces EV_SELECT_USE_FD_SET, too */
|
3349
|
+
.Ve
|
3350
|
+
.Sp
|
3351
|
+
Note that winsockets handling of fd sets is O(n), so you can easily get a
|
3352
|
+
complexity in the O(nA\*^X) range when using win32.
|
3353
|
+
.IP "Limited number of file descriptors" 4
|
3354
|
+
.IX Item "Limited number of file descriptors"
|
3355
|
+
Windows has numerous arbitrary (and low) limits on things.
|
3356
|
+
.Sp
|
3357
|
+
Early versions of winsocket's select only supported waiting for a maximum
|
3358
|
+
of \f(CW64\fR handles (probably owning to the fact that all windows kernels
|
3359
|
+
can only wait for \f(CW64\fR things at the same time internally; microsoft
|
3360
|
+
recommends spawning a chain of threads and wait for 63 handles and the
|
3361
|
+
previous thread in each. Great).
|
3362
|
+
.Sp
|
3363
|
+
Newer versions support more handles, but you need to define \f(CW\*(C`FD_SETSIZE\*(C'\fR
|
3364
|
+
to some high number (e.g. \f(CW2048\fR) before compiling the winsocket select
|
3365
|
+
call (which might be in libev or elsewhere, for example, perl does its own
|
3366
|
+
select emulation on windows).
|
3367
|
+
.Sp
|
3368
|
+
Another limit is the number of file descriptors in the microsoft runtime
|
3369
|
+
libraries, which by default is \f(CW64\fR (there must be a hidden \fI64\fR fetish
|
3370
|
+
or something like this inside microsoft). You can increase this by calling
|
3371
|
+
\&\f(CW\*(C`_setmaxstdio\*(C'\fR, which can increase this limit to \f(CW2048\fR (another
|
3372
|
+
arbitrary limit), but is broken in many versions of the microsoft runtime
|
3373
|
+
libraries.
|
3374
|
+
.Sp
|
3375
|
+
This might get you to about \f(CW512\fR or \f(CW2048\fR sockets (depending on
|
3376
|
+
windows version and/or the phase of the moon). To get more, you need to
|
3377
|
+
wrap all I/O functions and provide your own fd management, but the cost of
|
3378
|
+
calling select (O(nA\*^X)) will likely make this unworkable.
|
3379
|
+
.SH "PORTABILITY REQUIREMENTS"
|
3380
|
+
.IX Header "PORTABILITY REQUIREMENTS"
|
3381
|
+
In addition to a working ISO-C implementation, libev relies on a few
|
3382
|
+
additional extensions:
|
3383
|
+
.ie n .IP """sig_atomic_t volatile"" must be thread-atomic as well" 4
|
3384
|
+
.el .IP "\f(CWsig_atomic_t volatile\fR must be thread-atomic as well" 4
|
3385
|
+
.IX Item "sig_atomic_t volatile must be thread-atomic as well"
|
3386
|
+
The type \f(CW\*(C`sig_atomic_t volatile\*(C'\fR (or whatever is defined as
|
3387
|
+
\&\f(CW\*(C`EV_ATOMIC_T\*(C'\fR) must be atomic w.r.t. accesses from different
|
3388
|
+
threads. This is not part of the specification for \f(CW\*(C`sig_atomic_t\*(C'\fR, but is
|
3389
|
+
believed to be sufficiently portable.
|
3390
|
+
.ie n .IP """sigprocmask"" must work in a threaded environment" 4
|
3391
|
+
.el .IP "\f(CWsigprocmask\fR must work in a threaded environment" 4
|
3392
|
+
.IX Item "sigprocmask must work in a threaded environment"
|
3393
|
+
Libev uses \f(CW\*(C`sigprocmask\*(C'\fR to temporarily block signals. This is not
|
3394
|
+
allowed in a threaded program (\f(CW\*(C`pthread_sigmask\*(C'\fR has to be used). Typical
|
3395
|
+
pthread implementations will either allow \f(CW\*(C`sigprocmask\*(C'\fR in the \*(L"main
|
3396
|
+
thread\*(R" or will block signals process-wide, both behaviours would
|
3397
|
+
be compatible with libev. Interaction between \f(CW\*(C`sigprocmask\*(C'\fR and
|
3398
|
+
\&\f(CW\*(C`pthread_sigmask\*(C'\fR could complicate things, however.
|
3399
|
+
.Sp
|
3400
|
+
The most portable way to handle signals is to block signals in all threads
|
3401
|
+
except the initial one, and run the default loop in the initial thread as
|
3402
|
+
well.
|
3403
|
+
.ie n .IP """long"" must be large enough for common memory allocation sizes" 4
|
3404
|
+
.el .IP "\f(CWlong\fR must be large enough for common memory allocation sizes" 4
|
3405
|
+
.IX Item "long must be large enough for common memory allocation sizes"
|
3406
|
+
To improve portability and simplify using libev, libev uses \f(CW\*(C`long\*(C'\fR
|
3407
|
+
internally instead of \f(CW\*(C`size_t\*(C'\fR when allocating its data structures. On
|
3408
|
+
non-POSIX systems (Microsoft...) this might be unexpectedly low, but
|
3409
|
+
is still at least 31 bits everywhere, which is enough for hundreds of
|
3410
|
+
millions of watchers.
|
3411
|
+
.ie n .IP """double"" must hold a time value in seconds with enough accuracy" 4
|
3412
|
+
.el .IP "\f(CWdouble\fR must hold a time value in seconds with enough accuracy" 4
|
3413
|
+
.IX Item "double must hold a time value in seconds with enough accuracy"
|
3414
|
+
The type \f(CW\*(C`double\*(C'\fR is used to represent timestamps. It is required to
|
3415
|
+
have at least 51 bits of mantissa (and 9 bits of exponent), which is good
|
3416
|
+
enough for at least into the year 4000. This requirement is fulfilled by
|
3417
|
+
implementations implementing \s-1IEEE\s0 754 (basically all existing ones).
|
3418
|
+
.PP
|
3419
|
+
If you know of other additional requirements drop me a note.
|
3420
|
+
.SH "AUTHOR"
|
3421
|
+
.IX Header "AUTHOR"
|
3422
|
+
Marc Lehmann <libev@schmorp.de>.
|
3423
|
+
.SH "POD ERRORS"
|
3424
|
+
.IX Header "POD ERRORS"
|
3425
|
+
Hey! \fBThe above document had some coding errors, which are explained below:\fR
|
3426
|
+
.IP "Around line 3052:" 4
|
3427
|
+
.IX Item "Around line 3052:"
|
3428
|
+
You forgot a '=back' before '=head2'
|