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