… | |
… | |
1184 | #include <stddef.h> |
1184 | #include <stddef.h> |
1185 | |
1185 | |
1186 | static void |
1186 | static void |
1187 | t1_cb (EV_P_ ev_timer *w, int revents) |
1187 | t1_cb (EV_P_ ev_timer *w, int revents) |
1188 | { |
1188 | { |
1189 | struct my_biggy big = (struct my_biggy * |
1189 | struct my_biggy big = (struct my_biggy *) |
1190 | (((char *)w) - offsetof (struct my_biggy, t1)); |
1190 | (((char *)w) - offsetof (struct my_biggy, t1)); |
1191 | } |
1191 | } |
1192 | |
1192 | |
1193 | static void |
1193 | static void |
1194 | t2_cb (EV_P_ ev_timer *w, int revents) |
1194 | t2_cb (EV_P_ ev_timer *w, int revents) |
1195 | { |
1195 | { |
1196 | struct my_biggy big = (struct my_biggy * |
1196 | struct my_biggy big = (struct my_biggy *) |
1197 | (((char *)w) - offsetof (struct my_biggy, t2)); |
1197 | (((char *)w) - offsetof (struct my_biggy, t2)); |
1198 | } |
1198 | } |
1199 | |
1199 | |
1200 | =head2 WATCHER PRIORITY MODELS |
1200 | =head2 WATCHER PRIORITY MODELS |
1201 | |
1201 | |
… | |
… | |
1277 | // with the default priority are receiving events. |
1277 | // with the default priority are receiving events. |
1278 | ev_idle_start (EV_A_ &idle); |
1278 | ev_idle_start (EV_A_ &idle); |
1279 | } |
1279 | } |
1280 | |
1280 | |
1281 | static void |
1281 | static void |
1282 | idle-cb (EV_P_ ev_idle *w, int revents) |
1282 | idle_cb (EV_P_ ev_idle *w, int revents) |
1283 | { |
1283 | { |
1284 | // actual processing |
1284 | // actual processing |
1285 | read (STDIN_FILENO, ...); |
1285 | read (STDIN_FILENO, ...); |
1286 | |
1286 | |
1287 | // have to start the I/O watcher again, as |
1287 | // have to start the I/O watcher again, as |
… | |
… | |
1332 | descriptors to non-blocking mode is also usually a good idea (but not |
1332 | descriptors to non-blocking mode is also usually a good idea (but not |
1333 | required if you know what you are doing). |
1333 | required if you know what you are doing). |
1334 | |
1334 | |
1335 | If you cannot use non-blocking mode, then force the use of a |
1335 | If you cannot use non-blocking mode, then force the use of a |
1336 | known-to-be-good backend (at the time of this writing, this includes only |
1336 | known-to-be-good backend (at the time of this writing, this includes only |
1337 | C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). |
1337 | C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). The same applies to file |
|
|
1338 | descriptors for which non-blocking operation makes no sense (such as |
|
|
1339 | files) - libev doesn't guarentee any specific behaviour in that case. |
1338 | |
1340 | |
1339 | Another thing you have to watch out for is that it is quite easy to |
1341 | Another thing you have to watch out for is that it is quite easy to |
1340 | receive "spurious" readiness notifications, that is your callback might |
1342 | receive "spurious" readiness notifications, that is your callback might |
1341 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
1343 | be called with C<EV_READ> but a subsequent C<read>(2) will actually block |
1342 | because there is no data. Not only are some backends known to create a |
1344 | because there is no data. Not only are some backends known to create a |
… | |
… | |
1463 | year, it will still time out after (roughly) one hour. "Roughly" because |
1465 | year, it will still time out after (roughly) one hour. "Roughly" because |
1464 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1466 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1465 | monotonic clock option helps a lot here). |
1467 | monotonic clock option helps a lot here). |
1466 | |
1468 | |
1467 | The callback is guaranteed to be invoked only I<after> its timeout has |
1469 | The callback is guaranteed to be invoked only I<after> its timeout has |
1468 | passed. If multiple timers become ready during the same loop iteration |
1470 | passed (not I<at>, so on systems with very low-resolution clocks this |
1469 | then the ones with earlier time-out values are invoked before ones with |
1471 | might introduce a small delay). If multiple timers become ready during the |
|
|
1472 | same loop iteration then the ones with earlier time-out values are invoked |
1470 | later time-out values (but this is no longer true when a callback calls |
1473 | before ones with later time-out values (but this is no longer true when a |
1471 | C<ev_loop> recursively). |
1474 | callback calls C<ev_loop> recursively). |
1472 | |
1475 | |
1473 | =head3 Be smart about timeouts |
1476 | =head3 Be smart about timeouts |
1474 | |
1477 | |
1475 | Many real-world problems involve some kind of timeout, usually for error |
1478 | Many real-world problems involve some kind of timeout, usually for error |
1476 | recovery. A typical example is an HTTP request - if the other side hangs, |
1479 | recovery. A typical example is an HTTP request - if the other side hangs, |
… | |
… | |
1520 | C<after> argument to C<ev_timer_set>, and only ever use the C<repeat> |
1523 | C<after> argument to C<ev_timer_set>, and only ever use the C<repeat> |
1521 | member and C<ev_timer_again>. |
1524 | member and C<ev_timer_again>. |
1522 | |
1525 | |
1523 | At start: |
1526 | At start: |
1524 | |
1527 | |
1525 | ev_timer_init (timer, callback); |
1528 | ev_init (timer, callback); |
1526 | timer->repeat = 60.; |
1529 | timer->repeat = 60.; |
1527 | ev_timer_again (loop, timer); |
1530 | ev_timer_again (loop, timer); |
1528 | |
1531 | |
1529 | Each time there is some activity: |
1532 | Each time there is some activity: |
1530 | |
1533 | |
… | |
… | |
1592 | |
1595 | |
1593 | To start the timer, simply initialise the watcher and set C<last_activity> |
1596 | To start the timer, simply initialise the watcher and set C<last_activity> |
1594 | to the current time (meaning we just have some activity :), then call the |
1597 | to the current time (meaning we just have some activity :), then call the |
1595 | callback, which will "do the right thing" and start the timer: |
1598 | callback, which will "do the right thing" and start the timer: |
1596 | |
1599 | |
1597 | ev_timer_init (timer, callback); |
1600 | ev_init (timer, callback); |
1598 | last_activity = ev_now (loop); |
1601 | last_activity = ev_now (loop); |
1599 | callback (loop, timer, EV_TIMEOUT); |
1602 | callback (loop, timer, EV_TIMEOUT); |
1600 | |
1603 | |
1601 | And when there is some activity, simply store the current time in |
1604 | And when there is some activity, simply store the current time in |
1602 | C<last_activity>, no libev calls at all: |
1605 | C<last_activity>, no libev calls at all: |
… | |
… | |
2365 | // no longer anything immediate to do. |
2368 | // no longer anything immediate to do. |
2366 | } |
2369 | } |
2367 | |
2370 | |
2368 | ev_idle *idle_watcher = malloc (sizeof (ev_idle)); |
2371 | ev_idle *idle_watcher = malloc (sizeof (ev_idle)); |
2369 | ev_idle_init (idle_watcher, idle_cb); |
2372 | ev_idle_init (idle_watcher, idle_cb); |
2370 | ev_idle_start (loop, idle_cb); |
2373 | ev_idle_start (loop, idle_watcher); |
2371 | |
2374 | |
2372 | |
2375 | |
2373 | =head2 C<ev_prepare> and C<ev_check> - customise your event loop! |
2376 | =head2 C<ev_prepare> and C<ev_check> - customise your event loop! |
2374 | |
2377 | |
2375 | Prepare and check watchers are usually (but not always) used in pairs: |
2378 | Prepare and check watchers are usually (but not always) used in pairs: |
… | |
… | |
2468 | struct pollfd fds [nfd]; |
2471 | struct pollfd fds [nfd]; |
2469 | // actual code will need to loop here and realloc etc. |
2472 | // actual code will need to loop here and realloc etc. |
2470 | adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ())); |
2473 | adns_beforepoll (ads, fds, &nfd, &timeout, timeval_from (ev_time ())); |
2471 | |
2474 | |
2472 | /* the callback is illegal, but won't be called as we stop during check */ |
2475 | /* the callback is illegal, but won't be called as we stop during check */ |
2473 | ev_timer_init (&tw, 0, timeout * 1e-3); |
2476 | ev_timer_init (&tw, 0, timeout * 1e-3, 0.); |
2474 | ev_timer_start (loop, &tw); |
2477 | ev_timer_start (loop, &tw); |
2475 | |
2478 | |
2476 | // create one ev_io per pollfd |
2479 | // create one ev_io per pollfd |
2477 | for (int i = 0; i < nfd; ++i) |
2480 | for (int i = 0; i < nfd; ++i) |
2478 | { |
2481 | { |
… | |
… | |
3932 | way (note also that glib is the slowest event library known to man). |
3935 | way (note also that glib is the slowest event library known to man). |
3933 | |
3936 | |
3934 | There is no supported compilation method available on windows except |
3937 | There is no supported compilation method available on windows except |
3935 | embedding it into other applications. |
3938 | embedding it into other applications. |
3936 | |
3939 | |
|
|
3940 | Sensible signal handling is officially unsupported by Microsoft - libev |
|
|
3941 | tries its best, but under most conditions, signals will simply not work. |
|
|
3942 | |
3937 | Not a libev limitation but worth mentioning: windows apparently doesn't |
3943 | Not a libev limitation but worth mentioning: windows apparently doesn't |
3938 | accept large writes: instead of resulting in a partial write, windows will |
3944 | accept large writes: instead of resulting in a partial write, windows will |
3939 | either accept everything or return C<ENOBUFS> if the buffer is too large, |
3945 | either accept everything or return C<ENOBUFS> if the buffer is too large, |
3940 | so make sure you only write small amounts into your sockets (less than a |
3946 | so make sure you only write small amounts into your sockets (less than a |
3941 | megabyte seems safe, but this apparently depends on the amount of memory |
3947 | megabyte seems safe, but this apparently depends on the amount of memory |
… | |
… | |
3945 | the abysmal performance of winsockets, using a large number of sockets |
3951 | the abysmal performance of winsockets, using a large number of sockets |
3946 | is not recommended (and not reasonable). If your program needs to use |
3952 | is not recommended (and not reasonable). If your program needs to use |
3947 | more than a hundred or so sockets, then likely it needs to use a totally |
3953 | more than a hundred or so sockets, then likely it needs to use a totally |
3948 | different implementation for windows, as libev offers the POSIX readiness |
3954 | different implementation for windows, as libev offers the POSIX readiness |
3949 | notification model, which cannot be implemented efficiently on windows |
3955 | notification model, which cannot be implemented efficiently on windows |
3950 | (Microsoft monopoly games). |
3956 | (due to Microsoft monopoly games). |
3951 | |
3957 | |
3952 | A typical way to use libev under windows is to embed it (see the embedding |
3958 | A typical way to use libev under windows is to embed it (see the embedding |
3953 | section for details) and use the following F<evwrap.h> header file instead |
3959 | section for details) and use the following F<evwrap.h> header file instead |
3954 | of F<ev.h>: |
3960 | of F<ev.h>: |
3955 | |
3961 | |
… | |
… | |
3991 | |
3997 | |
3992 | Early versions of winsocket's select only supported waiting for a maximum |
3998 | Early versions of winsocket's select only supported waiting for a maximum |
3993 | of C<64> handles (probably owning to the fact that all windows kernels |
3999 | of C<64> handles (probably owning to the fact that all windows kernels |
3994 | can only wait for C<64> things at the same time internally; Microsoft |
4000 | can only wait for C<64> things at the same time internally; Microsoft |
3995 | recommends spawning a chain of threads and wait for 63 handles and the |
4001 | recommends spawning a chain of threads and wait for 63 handles and the |
3996 | previous thread in each. Great). |
4002 | previous thread in each. Sounds great!). |
3997 | |
4003 | |
3998 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
4004 | Newer versions support more handles, but you need to define C<FD_SETSIZE> |
3999 | to some high number (e.g. C<2048>) before compiling the winsocket select |
4005 | to some high number (e.g. C<2048>) before compiling the winsocket select |
4000 | call (which might be in libev or elsewhere, for example, perl does its own |
4006 | call (which might be in libev or elsewhere, for example, perl and many |
4001 | select emulation on windows). |
4007 | other interpreters do their own select emulation on windows). |
4002 | |
4008 | |
4003 | Another limit is the number of file descriptors in the Microsoft runtime |
4009 | Another limit is the number of file descriptors in the Microsoft runtime |
4004 | libraries, which by default is C<64> (there must be a hidden I<64> fetish |
4010 | libraries, which by default is C<64> (there must be a hidden I<64> |
4005 | or something like this inside Microsoft). You can increase this by calling |
4011 | fetish or something like this inside Microsoft). You can increase this |
4006 | C<_setmaxstdio>, which can increase this limit to C<2048> (another |
4012 | by calling C<_setmaxstdio>, which can increase this limit to C<2048> |
4007 | arbitrary limit), but is broken in many versions of the Microsoft runtime |
4013 | (another arbitrary limit), but is broken in many versions of the Microsoft |
4008 | libraries. |
|
|
4009 | |
|
|
4010 | This might get you to about C<512> or C<2048> sockets (depending on |
4014 | runtime libraries. This might get you to about C<512> or C<2048> sockets |
4011 | windows version and/or the phase of the moon). To get more, you need to |
4015 | (depending on windows version and/or the phase of the moon). To get more, |
4012 | wrap all I/O functions and provide your own fd management, but the cost of |
4016 | you need to wrap all I/O functions and provide your own fd management, but |
4013 | calling select (O(n²)) will likely make this unworkable. |
4017 | the cost of calling select (O(n²)) will likely make this unworkable. |
4014 | |
4018 | |
4015 | =back |
4019 | =back |
4016 | |
4020 | |
4017 | =head2 PORTABILITY REQUIREMENTS |
4021 | =head2 PORTABILITY REQUIREMENTS |
4018 | |
4022 | |