asyncengine 0.0.1.testing

Sign up to get free protection for your applications and to get access to all the features.
Files changed (317) hide show
  1. data/README.markdown +0 -0
  2. data/asyncengine.gemspec +26 -0
  3. data/ext/asyncengine_ext/asyncengine_ruby.c +82 -0
  4. data/ext/asyncengine_ext/extconf.rb +47 -0
  5. data/ext/asyncengine_ext/libuv/AUTHORS +45 -0
  6. data/ext/asyncengine_ext/libuv/LICENSE +42 -0
  7. data/ext/asyncengine_ext/libuv/Makefile +119 -0
  8. data/ext/asyncengine_ext/libuv/README.md +88 -0
  9. data/ext/asyncengine_ext/libuv/build/gcc_version.py +20 -0
  10. data/ext/asyncengine_ext/libuv/common.gypi +176 -0
  11. data/ext/asyncengine_ext/libuv/config-mingw.mk +61 -0
  12. data/ext/asyncengine_ext/libuv/config-unix.mk +173 -0
  13. data/ext/asyncengine_ext/libuv/gyp_uv +60 -0
  14. data/ext/asyncengine_ext/libuv/include/ares.h +591 -0
  15. data/ext/asyncengine_ext/libuv/include/ares_version.h +24 -0
  16. data/ext/asyncengine_ext/libuv/include/uv-private/eio.h +403 -0
  17. data/ext/asyncengine_ext/libuv/include/uv-private/ev.h +838 -0
  18. data/ext/asyncengine_ext/libuv/include/uv-private/ngx-queue.h +106 -0
  19. data/ext/asyncengine_ext/libuv/include/uv-private/tree.h +768 -0
  20. data/ext/asyncengine_ext/libuv/include/uv-private/uv-unix.h +256 -0
  21. data/ext/asyncengine_ext/libuv/include/uv-private/uv-win.h +458 -0
  22. data/ext/asyncengine_ext/libuv/include/uv.h +1556 -0
  23. data/ext/asyncengine_ext/libuv/src/ares/AUTHORS +37 -0
  24. data/ext/asyncengine_ext/libuv/src/ares/CHANGES +1218 -0
  25. data/ext/asyncengine_ext/libuv/src/ares/CMakeLists.txt +22 -0
  26. data/ext/asyncengine_ext/libuv/src/ares/NEWS +21 -0
  27. data/ext/asyncengine_ext/libuv/src/ares/README +60 -0
  28. data/ext/asyncengine_ext/libuv/src/ares/README.cares +13 -0
  29. data/ext/asyncengine_ext/libuv/src/ares/README.msvc +142 -0
  30. data/ext/asyncengine_ext/libuv/src/ares/README.node +21 -0
  31. data/ext/asyncengine_ext/libuv/src/ares/RELEASE-NOTES +26 -0
  32. data/ext/asyncengine_ext/libuv/src/ares/TODO +23 -0
  33. data/ext/asyncengine_ext/libuv/src/ares/ares__close_sockets.c +66 -0
  34. data/ext/asyncengine_ext/libuv/src/ares/ares__get_hostent.c +263 -0
  35. data/ext/asyncengine_ext/libuv/src/ares/ares__read_line.c +71 -0
  36. data/ext/asyncengine_ext/libuv/src/ares/ares__timeval.c +111 -0
  37. data/ext/asyncengine_ext/libuv/src/ares/ares_cancel.c +63 -0
  38. data/ext/asyncengine_ext/libuv/src/ares/ares_data.c +190 -0
  39. data/ext/asyncengine_ext/libuv/src/ares/ares_data.h +65 -0
  40. data/ext/asyncengine_ext/libuv/src/ares/ares_destroy.c +105 -0
  41. data/ext/asyncengine_ext/libuv/src/ares/ares_dns.h +90 -0
  42. data/ext/asyncengine_ext/libuv/src/ares/ares_expand_name.c +200 -0
  43. data/ext/asyncengine_ext/libuv/src/ares/ares_expand_string.c +75 -0
  44. data/ext/asyncengine_ext/libuv/src/ares/ares_fds.c +63 -0
  45. data/ext/asyncengine_ext/libuv/src/ares/ares_free_hostent.c +42 -0
  46. data/ext/asyncengine_ext/libuv/src/ares/ares_free_string.c +25 -0
  47. data/ext/asyncengine_ext/libuv/src/ares/ares_getenv.c +30 -0
  48. data/ext/asyncengine_ext/libuv/src/ares/ares_getenv.h +26 -0
  49. data/ext/asyncengine_ext/libuv/src/ares/ares_gethostbyaddr.c +301 -0
  50. data/ext/asyncengine_ext/libuv/src/ares/ares_gethostbyname.c +523 -0
  51. data/ext/asyncengine_ext/libuv/src/ares/ares_getnameinfo.c +427 -0
  52. data/ext/asyncengine_ext/libuv/src/ares/ares_getopt.c +122 -0
  53. data/ext/asyncengine_ext/libuv/src/ares/ares_getopt.h +53 -0
  54. data/ext/asyncengine_ext/libuv/src/ares/ares_getsock.c +72 -0
  55. data/ext/asyncengine_ext/libuv/src/ares/ares_init.c +1809 -0
  56. data/ext/asyncengine_ext/libuv/src/ares/ares_iphlpapi.h +221 -0
  57. data/ext/asyncengine_ext/libuv/src/ares/ares_ipv6.h +78 -0
  58. data/ext/asyncengine_ext/libuv/src/ares/ares_library_init.c +142 -0
  59. data/ext/asyncengine_ext/libuv/src/ares/ares_library_init.h +42 -0
  60. data/ext/asyncengine_ext/libuv/src/ares/ares_llist.c +86 -0
  61. data/ext/asyncengine_ext/libuv/src/ares/ares_llist.h +42 -0
  62. data/ext/asyncengine_ext/libuv/src/ares/ares_mkquery.c +195 -0
  63. data/ext/asyncengine_ext/libuv/src/ares/ares_nowarn.c +181 -0
  64. data/ext/asyncengine_ext/libuv/src/ares/ares_nowarn.h +55 -0
  65. data/ext/asyncengine_ext/libuv/src/ares/ares_options.c +248 -0
  66. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_a_reply.c +263 -0
  67. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_aaaa_reply.c +259 -0
  68. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_mx_reply.c +170 -0
  69. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_ns_reply.c +182 -0
  70. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_ptr_reply.c +217 -0
  71. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_srv_reply.c +179 -0
  72. data/ext/asyncengine_ext/libuv/src/ares/ares_parse_txt_reply.c +201 -0
  73. data/ext/asyncengine_ext/libuv/src/ares/ares_platform.c +11035 -0
  74. data/ext/asyncengine_ext/libuv/src/ares/ares_platform.h +43 -0
  75. data/ext/asyncengine_ext/libuv/src/ares/ares_private.h +355 -0
  76. data/ext/asyncengine_ext/libuv/src/ares/ares_process.c +1295 -0
  77. data/ext/asyncengine_ext/libuv/src/ares/ares_query.c +183 -0
  78. data/ext/asyncengine_ext/libuv/src/ares/ares_rules.h +144 -0
  79. data/ext/asyncengine_ext/libuv/src/ares/ares_search.c +321 -0
  80. data/ext/asyncengine_ext/libuv/src/ares/ares_send.c +134 -0
  81. data/ext/asyncengine_ext/libuv/src/ares/ares_setup.h +199 -0
  82. data/ext/asyncengine_ext/libuv/src/ares/ares_strcasecmp.c +66 -0
  83. data/ext/asyncengine_ext/libuv/src/ares/ares_strcasecmp.h +30 -0
  84. data/ext/asyncengine_ext/libuv/src/ares/ares_strdup.c +42 -0
  85. data/ext/asyncengine_ext/libuv/src/ares/ares_strdup.h +26 -0
  86. data/ext/asyncengine_ext/libuv/src/ares/ares_strerror.c +56 -0
  87. data/ext/asyncengine_ext/libuv/src/ares/ares_timeout.c +80 -0
  88. data/ext/asyncengine_ext/libuv/src/ares/ares_version.c +11 -0
  89. data/ext/asyncengine_ext/libuv/src/ares/ares_writev.c +79 -0
  90. data/ext/asyncengine_ext/libuv/src/ares/ares_writev.h +36 -0
  91. data/ext/asyncengine_ext/libuv/src/ares/bitncmp.c +59 -0
  92. data/ext/asyncengine_ext/libuv/src/ares/bitncmp.h +26 -0
  93. data/ext/asyncengine_ext/libuv/src/ares/config_cygwin/ares_config.h +512 -0
  94. data/ext/asyncengine_ext/libuv/src/ares/config_darwin/ares_config.h +512 -0
  95. data/ext/asyncengine_ext/libuv/src/ares/config_freebsd/ares_config.h +512 -0
  96. data/ext/asyncengine_ext/libuv/src/ares/config_linux/ares_config.h +512 -0
  97. data/ext/asyncengine_ext/libuv/src/ares/config_netbsd/ares_config.h +512 -0
  98. data/ext/asyncengine_ext/libuv/src/ares/config_openbsd/ares_config.h +512 -0
  99. data/ext/asyncengine_ext/libuv/src/ares/config_sunos/ares_config.h +512 -0
  100. data/ext/asyncengine_ext/libuv/src/ares/config_win32/ares_config.h +369 -0
  101. data/ext/asyncengine_ext/libuv/src/ares/get_ver.awk +35 -0
  102. data/ext/asyncengine_ext/libuv/src/ares/inet_net_pton.c +451 -0
  103. data/ext/asyncengine_ext/libuv/src/ares/inet_net_pton.h +31 -0
  104. data/ext/asyncengine_ext/libuv/src/ares/inet_ntop.c +208 -0
  105. data/ext/asyncengine_ext/libuv/src/ares/inet_ntop.h +26 -0
  106. data/ext/asyncengine_ext/libuv/src/ares/nameser.h +203 -0
  107. data/ext/asyncengine_ext/libuv/src/ares/setup_once.h +504 -0
  108. data/ext/asyncengine_ext/libuv/src/ares/windows_port.c +22 -0
  109. data/ext/asyncengine_ext/libuv/src/unix/async.c +58 -0
  110. data/ext/asyncengine_ext/libuv/src/unix/cares.c +194 -0
  111. data/ext/asyncengine_ext/libuv/src/unix/check.c +80 -0
  112. data/ext/asyncengine_ext/libuv/src/unix/core.c +588 -0
  113. data/ext/asyncengine_ext/libuv/src/unix/cygwin.c +84 -0
  114. data/ext/asyncengine_ext/libuv/src/unix/darwin.c +341 -0
  115. data/ext/asyncengine_ext/libuv/src/unix/dl.c +91 -0
  116. data/ext/asyncengine_ext/libuv/src/unix/eio/Changes +63 -0
  117. data/ext/asyncengine_ext/libuv/src/unix/eio/LICENSE +36 -0
  118. data/ext/asyncengine_ext/libuv/src/unix/eio/Makefile.am +15 -0
  119. data/ext/asyncengine_ext/libuv/src/unix/eio/aclocal.m4 +8957 -0
  120. data/ext/asyncengine_ext/libuv/src/unix/eio/autogen.sh +3 -0
  121. data/ext/asyncengine_ext/libuv/src/unix/eio/config.h.in +86 -0
  122. data/ext/asyncengine_ext/libuv/src/unix/eio/config_cygwin.h +80 -0
  123. data/ext/asyncengine_ext/libuv/src/unix/eio/config_darwin.h +141 -0
  124. data/ext/asyncengine_ext/libuv/src/unix/eio/config_freebsd.h +81 -0
  125. data/ext/asyncengine_ext/libuv/src/unix/eio/config_linux.h +94 -0
  126. data/ext/asyncengine_ext/libuv/src/unix/eio/config_netbsd.h +81 -0
  127. data/ext/asyncengine_ext/libuv/src/unix/eio/config_openbsd.h +137 -0
  128. data/ext/asyncengine_ext/libuv/src/unix/eio/config_sunos.h +84 -0
  129. data/ext/asyncengine_ext/libuv/src/unix/eio/configure.ac +22 -0
  130. data/ext/asyncengine_ext/libuv/src/unix/eio/demo.c +194 -0
  131. data/ext/asyncengine_ext/libuv/src/unix/eio/ecb.h +370 -0
  132. data/ext/asyncengine_ext/libuv/src/unix/eio/eio.3 +3428 -0
  133. data/ext/asyncengine_ext/libuv/src/unix/eio/eio.c +2593 -0
  134. data/ext/asyncengine_ext/libuv/src/unix/eio/eio.pod +969 -0
  135. data/ext/asyncengine_ext/libuv/src/unix/eio/libeio.m4 +195 -0
  136. data/ext/asyncengine_ext/libuv/src/unix/eio/xthread.h +164 -0
  137. data/ext/asyncengine_ext/libuv/src/unix/error.c +98 -0
  138. data/ext/asyncengine_ext/libuv/src/unix/ev/Changes +388 -0
  139. data/ext/asyncengine_ext/libuv/src/unix/ev/LICENSE +36 -0
  140. data/ext/asyncengine_ext/libuv/src/unix/ev/Makefile.am +18 -0
  141. data/ext/asyncengine_ext/libuv/src/unix/ev/Makefile.in +771 -0
  142. data/ext/asyncengine_ext/libuv/src/unix/ev/README +58 -0
  143. data/ext/asyncengine_ext/libuv/src/unix/ev/aclocal.m4 +8957 -0
  144. data/ext/asyncengine_ext/libuv/src/unix/ev/autogen.sh +6 -0
  145. data/ext/asyncengine_ext/libuv/src/unix/ev/config.guess +1526 -0
  146. data/ext/asyncengine_ext/libuv/src/unix/ev/config.h.in +125 -0
  147. data/ext/asyncengine_ext/libuv/src/unix/ev/config.sub +1658 -0
  148. data/ext/asyncengine_ext/libuv/src/unix/ev/config_cygwin.h +123 -0
  149. data/ext/asyncengine_ext/libuv/src/unix/ev/config_darwin.h +122 -0
  150. data/ext/asyncengine_ext/libuv/src/unix/ev/config_freebsd.h +120 -0
  151. data/ext/asyncengine_ext/libuv/src/unix/ev/config_linux.h +141 -0
  152. data/ext/asyncengine_ext/libuv/src/unix/ev/config_netbsd.h +120 -0
  153. data/ext/asyncengine_ext/libuv/src/unix/ev/config_openbsd.h +126 -0
  154. data/ext/asyncengine_ext/libuv/src/unix/ev/config_sunos.h +122 -0
  155. data/ext/asyncengine_ext/libuv/src/unix/ev/configure +13037 -0
  156. data/ext/asyncengine_ext/libuv/src/unix/ev/configure.ac +18 -0
  157. data/ext/asyncengine_ext/libuv/src/unix/ev/depcomp +630 -0
  158. data/ext/asyncengine_ext/libuv/src/unix/ev/ev++.h +816 -0
  159. data/ext/asyncengine_ext/libuv/src/unix/ev/ev.3 +5311 -0
  160. data/ext/asyncengine_ext/libuv/src/unix/ev/ev.c +3921 -0
  161. data/ext/asyncengine_ext/libuv/src/unix/ev/ev.pod +5243 -0
  162. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_epoll.c +266 -0
  163. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_kqueue.c +235 -0
  164. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_poll.c +148 -0
  165. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_port.c +179 -0
  166. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_select.c +310 -0
  167. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_vars.h +203 -0
  168. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_win32.c +153 -0
  169. data/ext/asyncengine_ext/libuv/src/unix/ev/ev_wrap.h +196 -0
  170. data/ext/asyncengine_ext/libuv/src/unix/ev/event.c +402 -0
  171. data/ext/asyncengine_ext/libuv/src/unix/ev/event.h +170 -0
  172. data/ext/asyncengine_ext/libuv/src/unix/ev/install-sh +294 -0
  173. data/ext/asyncengine_ext/libuv/src/unix/ev/libev.m4 +39 -0
  174. data/ext/asyncengine_ext/libuv/src/unix/ev/ltmain.sh +8413 -0
  175. data/ext/asyncengine_ext/libuv/src/unix/ev/missing +336 -0
  176. data/ext/asyncengine_ext/libuv/src/unix/ev/mkinstalldirs +111 -0
  177. data/ext/asyncengine_ext/libuv/src/unix/freebsd.c +312 -0
  178. data/ext/asyncengine_ext/libuv/src/unix/fs.c +707 -0
  179. data/ext/asyncengine_ext/libuv/src/unix/idle.c +79 -0
  180. data/ext/asyncengine_ext/libuv/src/unix/internal.h +161 -0
  181. data/ext/asyncengine_ext/libuv/src/unix/kqueue.c +127 -0
  182. data/ext/asyncengine_ext/libuv/src/unix/linux/core.c +474 -0
  183. data/ext/asyncengine_ext/libuv/src/unix/linux/inotify.c +211 -0
  184. data/ext/asyncengine_ext/libuv/src/unix/linux/syscalls.c +230 -0
  185. data/ext/asyncengine_ext/libuv/src/unix/linux/syscalls.h +87 -0
  186. data/ext/asyncengine_ext/libuv/src/unix/loop.c +58 -0
  187. data/ext/asyncengine_ext/libuv/src/unix/netbsd.c +108 -0
  188. data/ext/asyncengine_ext/libuv/src/unix/openbsd.c +295 -0
  189. data/ext/asyncengine_ext/libuv/src/unix/pipe.c +266 -0
  190. data/ext/asyncengine_ext/libuv/src/unix/prepare.c +79 -0
  191. data/ext/asyncengine_ext/libuv/src/unix/process.c +369 -0
  192. data/ext/asyncengine_ext/libuv/src/unix/stream.c +1033 -0
  193. data/ext/asyncengine_ext/libuv/src/unix/sunos.c +466 -0
  194. data/ext/asyncengine_ext/libuv/src/unix/tcp.c +327 -0
  195. data/ext/asyncengine_ext/libuv/src/unix/thread.c +154 -0
  196. data/ext/asyncengine_ext/libuv/src/unix/timer.c +127 -0
  197. data/ext/asyncengine_ext/libuv/src/unix/tty.c +146 -0
  198. data/ext/asyncengine_ext/libuv/src/unix/udp.c +670 -0
  199. data/ext/asyncengine_ext/libuv/src/unix/uv-eio.c +124 -0
  200. data/ext/asyncengine_ext/libuv/src/unix/uv-eio.h +13 -0
  201. data/ext/asyncengine_ext/libuv/src/uv-common.c +354 -0
  202. data/ext/asyncengine_ext/libuv/src/uv-common.h +87 -0
  203. data/ext/asyncengine_ext/libuv/src/win/async.c +127 -0
  204. data/ext/asyncengine_ext/libuv/src/win/cares.c +290 -0
  205. data/ext/asyncengine_ext/libuv/src/win/core.c +270 -0
  206. data/ext/asyncengine_ext/libuv/src/win/dl.c +82 -0
  207. data/ext/asyncengine_ext/libuv/src/win/error.c +132 -0
  208. data/ext/asyncengine_ext/libuv/src/win/fs-event.c +514 -0
  209. data/ext/asyncengine_ext/libuv/src/win/fs.c +1576 -0
  210. data/ext/asyncengine_ext/libuv/src/win/getaddrinfo.c +372 -0
  211. data/ext/asyncengine_ext/libuv/src/win/handle.c +225 -0
  212. data/ext/asyncengine_ext/libuv/src/win/internal.h +352 -0
  213. data/ext/asyncengine_ext/libuv/src/win/loop-watcher.c +131 -0
  214. data/ext/asyncengine_ext/libuv/src/win/pipe.c +1661 -0
  215. data/ext/asyncengine_ext/libuv/src/win/process.c +1140 -0
  216. data/ext/asyncengine_ext/libuv/src/win/req.c +174 -0
  217. data/ext/asyncengine_ext/libuv/src/win/stream.c +201 -0
  218. data/ext/asyncengine_ext/libuv/src/win/tcp.c +1282 -0
  219. data/ext/asyncengine_ext/libuv/src/win/thread.c +332 -0
  220. data/ext/asyncengine_ext/libuv/src/win/threadpool.c +73 -0
  221. data/ext/asyncengine_ext/libuv/src/win/timer.c +276 -0
  222. data/ext/asyncengine_ext/libuv/src/win/tty.c +1795 -0
  223. data/ext/asyncengine_ext/libuv/src/win/udp.c +709 -0
  224. data/ext/asyncengine_ext/libuv/src/win/util.c +719 -0
  225. data/ext/asyncengine_ext/libuv/src/win/winapi.c +117 -0
  226. data/ext/asyncengine_ext/libuv/src/win/winapi.h +4419 -0
  227. data/ext/asyncengine_ext/libuv/src/win/winsock.c +470 -0
  228. data/ext/asyncengine_ext/libuv/src/win/winsock.h +138 -0
  229. data/ext/asyncengine_ext/libuv/test/benchmark-ares.c +118 -0
  230. data/ext/asyncengine_ext/libuv/test/benchmark-getaddrinfo.c +94 -0
  231. data/ext/asyncengine_ext/libuv/test/benchmark-list.h +105 -0
  232. data/ext/asyncengine_ext/libuv/test/benchmark-ping-pongs.c +213 -0
  233. data/ext/asyncengine_ext/libuv/test/benchmark-pound.c +324 -0
  234. data/ext/asyncengine_ext/libuv/test/benchmark-pump.c +462 -0
  235. data/ext/asyncengine_ext/libuv/test/benchmark-sizes.c +40 -0
  236. data/ext/asyncengine_ext/libuv/test/benchmark-spawn.c +156 -0
  237. data/ext/asyncengine_ext/libuv/test/benchmark-tcp-write-batch.c +140 -0
  238. data/ext/asyncengine_ext/libuv/test/benchmark-thread.c +64 -0
  239. data/ext/asyncengine_ext/libuv/test/benchmark-udp-packet-storm.c +247 -0
  240. data/ext/asyncengine_ext/libuv/test/blackhole-server.c +118 -0
  241. data/ext/asyncengine_ext/libuv/test/dns-server.c +321 -0
  242. data/ext/asyncengine_ext/libuv/test/echo-server.c +370 -0
  243. data/ext/asyncengine_ext/libuv/test/fixtures/empty_file +0 -0
  244. data/ext/asyncengine_ext/libuv/test/fixtures/load_error.node +1 -0
  245. data/ext/asyncengine_ext/libuv/test/run-benchmarks.c +64 -0
  246. data/ext/asyncengine_ext/libuv/test/run-tests.c +108 -0
  247. data/ext/asyncengine_ext/libuv/test/runner-unix.c +315 -0
  248. data/ext/asyncengine_ext/libuv/test/runner-unix.h +36 -0
  249. data/ext/asyncengine_ext/libuv/test/runner-win.c +343 -0
  250. data/ext/asyncengine_ext/libuv/test/runner-win.h +42 -0
  251. data/ext/asyncengine_ext/libuv/test/runner.c +317 -0
  252. data/ext/asyncengine_ext/libuv/test/runner.h +159 -0
  253. data/ext/asyncengine_ext/libuv/test/task.h +117 -0
  254. data/ext/asyncengine_ext/libuv/test/test-async.c +216 -0
  255. data/ext/asyncengine_ext/libuv/test/test-callback-stack.c +203 -0
  256. data/ext/asyncengine_ext/libuv/test/test-connection-fail.c +148 -0
  257. data/ext/asyncengine_ext/libuv/test/test-counters-init.c +216 -0
  258. data/ext/asyncengine_ext/libuv/test/test-cwd-and-chdir.c +64 -0
  259. data/ext/asyncengine_ext/libuv/test/test-delayed-accept.c +197 -0
  260. data/ext/asyncengine_ext/libuv/test/test-dlerror.c +49 -0
  261. data/ext/asyncengine_ext/libuv/test/test-eio-overflow.c +90 -0
  262. data/ext/asyncengine_ext/libuv/test/test-error.c +59 -0
  263. data/ext/asyncengine_ext/libuv/test/test-fail-always.c +29 -0
  264. data/ext/asyncengine_ext/libuv/test/test-fs-event.c +442 -0
  265. data/ext/asyncengine_ext/libuv/test/test-fs.c +1731 -0
  266. data/ext/asyncengine_ext/libuv/test/test-get-currentexe.c +63 -0
  267. data/ext/asyncengine_ext/libuv/test/test-get-loadavg.c +36 -0
  268. data/ext/asyncengine_ext/libuv/test/test-get-memory.c +38 -0
  269. data/ext/asyncengine_ext/libuv/test/test-getaddrinfo.c +122 -0
  270. data/ext/asyncengine_ext/libuv/test/test-gethostbyname.c +189 -0
  271. data/ext/asyncengine_ext/libuv/test/test-getsockname.c +342 -0
  272. data/ext/asyncengine_ext/libuv/test/test-hrtime.c +51 -0
  273. data/ext/asyncengine_ext/libuv/test/test-idle.c +81 -0
  274. data/ext/asyncengine_ext/libuv/test/test-ipc-send-recv.c +209 -0
  275. data/ext/asyncengine_ext/libuv/test/test-ipc.c +614 -0
  276. data/ext/asyncengine_ext/libuv/test/test-list.h +371 -0
  277. data/ext/asyncengine_ext/libuv/test/test-loop-handles.c +359 -0
  278. data/ext/asyncengine_ext/libuv/test/test-multiple-listen.c +102 -0
  279. data/ext/asyncengine_ext/libuv/test/test-mutexes.c +63 -0
  280. data/ext/asyncengine_ext/libuv/test/test-pass-always.c +28 -0
  281. data/ext/asyncengine_ext/libuv/test/test-ping-pong.c +253 -0
  282. data/ext/asyncengine_ext/libuv/test/test-pipe-bind-error.c +140 -0
  283. data/ext/asyncengine_ext/libuv/test/test-pipe-connect-error.c +96 -0
  284. data/ext/asyncengine_ext/libuv/test/test-platform-output.c +87 -0
  285. data/ext/asyncengine_ext/libuv/test/test-process-title.c +42 -0
  286. data/ext/asyncengine_ext/libuv/test/test-ref.c +322 -0
  287. data/ext/asyncengine_ext/libuv/test/test-run-once.c +44 -0
  288. data/ext/asyncengine_ext/libuv/test/test-shutdown-close.c +103 -0
  289. data/ext/asyncengine_ext/libuv/test/test-shutdown-eof.c +183 -0
  290. data/ext/asyncengine_ext/libuv/test/test-spawn.c +499 -0
  291. data/ext/asyncengine_ext/libuv/test/test-stdio-over-pipes.c +256 -0
  292. data/ext/asyncengine_ext/libuv/test/test-tcp-bind-error.c +191 -0
  293. data/ext/asyncengine_ext/libuv/test/test-tcp-bind6-error.c +154 -0
  294. data/ext/asyncengine_ext/libuv/test/test-tcp-close.c +129 -0
  295. data/ext/asyncengine_ext/libuv/test/test-tcp-connect-error.c +70 -0
  296. data/ext/asyncengine_ext/libuv/test/test-tcp-connect6-error.c +68 -0
  297. data/ext/asyncengine_ext/libuv/test/test-tcp-flags.c +51 -0
  298. data/ext/asyncengine_ext/libuv/test/test-tcp-write-error.c +168 -0
  299. data/ext/asyncengine_ext/libuv/test/test-tcp-write-to-half-open-connection.c +135 -0
  300. data/ext/asyncengine_ext/libuv/test/test-tcp-writealot.c +195 -0
  301. data/ext/asyncengine_ext/libuv/test/test-thread.c +183 -0
  302. data/ext/asyncengine_ext/libuv/test/test-threadpool.c +57 -0
  303. data/ext/asyncengine_ext/libuv/test/test-timer-again.c +141 -0
  304. data/ext/asyncengine_ext/libuv/test/test-timer.c +130 -0
  305. data/ext/asyncengine_ext/libuv/test/test-tty.c +110 -0
  306. data/ext/asyncengine_ext/libuv/test/test-udp-dgram-too-big.c +86 -0
  307. data/ext/asyncengine_ext/libuv/test/test-udp-ipv6.c +156 -0
  308. data/ext/asyncengine_ext/libuv/test/test-udp-multicast-join.c +139 -0
  309. data/ext/asyncengine_ext/libuv/test/test-udp-multicast-ttl.c +86 -0
  310. data/ext/asyncengine_ext/libuv/test/test-udp-options.c +86 -0
  311. data/ext/asyncengine_ext/libuv/test/test-udp-send-and-recv.c +208 -0
  312. data/ext/asyncengine_ext/libuv/test/test-util.c +97 -0
  313. data/ext/asyncengine_ext/libuv/uv.gyp +435 -0
  314. data/ext/asyncengine_ext/libuv/vcbuild.bat +105 -0
  315. data/lib/asyncengine/version.rb +3 -0
  316. data/lib/asyncengine.rb +41 -0
  317. 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'