… | |
… | |
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, |
… | |
… | |
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 | |