… | |
… | |
1465 | 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 |
1466 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1466 | detecting time jumps is hard, and some inaccuracies are unavoidable (the |
1467 | monotonic clock option helps a lot here). |
1467 | monotonic clock option helps a lot here). |
1468 | |
1468 | |
1469 | 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 |
1470 | 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 |
1471 | 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 |
1472 | 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 |
1473 | C<ev_loop> recursively). |
1474 | callback calls C<ev_loop> recursively). |
1474 | |
1475 | |
1475 | =head3 Be smart about timeouts |
1476 | =head3 Be smart about timeouts |
1476 | |
1477 | |
1477 | 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 |
1478 | 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, |
… | |
… | |
3934 | 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). |
3935 | |
3936 | |
3936 | There is no supported compilation method available on windows except |
3937 | There is no supported compilation method available on windows except |
3937 | embedding it into other applications. |
3938 | embedding it into other applications. |
3938 | |
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 | |
3939 | Not a libev limitation but worth mentioning: windows apparently doesn't |
3943 | Not a libev limitation but worth mentioning: windows apparently doesn't |
3940 | 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 |
3941 | 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, |
3942 | 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 |
3943 | 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 |
… | |
… | |
3947 | the abysmal performance of winsockets, using a large number of sockets |
3951 | the abysmal performance of winsockets, using a large number of sockets |
3948 | 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 |
3949 | 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 |
3950 | different implementation for windows, as libev offers the POSIX readiness |
3954 | different implementation for windows, as libev offers the POSIX readiness |
3951 | notification model, which cannot be implemented efficiently on windows |
3955 | notification model, which cannot be implemented efficiently on windows |
3952 | (Microsoft monopoly games). |
3956 | (due to Microsoft monopoly games). |
3953 | |
3957 | |
3954 | 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 |
3955 | 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 |
3956 | of F<ev.h>: |
3960 | of F<ev.h>: |
3957 | |
3961 | |
… | |
… | |
3993 | |
3997 | |
3994 | 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 |
3995 | 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 |
3996 | 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 |
3997 | 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 |
3998 | previous thread in each. Great). |
4002 | previous thread in each. Sounds great!). |
3999 | |
4003 | |
4000 | 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> |
4001 | 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 |
4002 | 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 |
4003 | select emulation on windows). |
4007 | other interpreters do their own select emulation on windows). |
4004 | |
4008 | |
4005 | 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 |
4006 | 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> |
4007 | or something like this inside Microsoft). You can increase this by calling |
4011 | fetish or something like this inside Microsoft). You can increase this |
4008 | C<_setmaxstdio>, which can increase this limit to C<2048> (another |
4012 | by calling C<_setmaxstdio>, which can increase this limit to C<2048> |
4009 | 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 |
4010 | libraries. |
|
|
4011 | |
|
|
4012 | 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 |
4013 | 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, |
4014 | 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 |
4015 | calling select (O(n²)) will likely make this unworkable. |
4017 | the cost of calling select (O(n²)) will likely make this unworkable. |
4016 | |
4018 | |
4017 | =back |
4019 | =back |
4018 | |
4020 | |
4019 | =head2 PORTABILITY REQUIREMENTS |
4021 | =head2 PORTABILITY REQUIREMENTS |
4020 | |
4022 | |