ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.238 by root, Sat Apr 18 12:10:41 2009 UTC vs.
Revision 1.240 by root, Sat Apr 25 14:12:48 2009 UTC

1332descriptors to non-blocking mode is also usually a good idea (but not 1332descriptors to non-blocking mode is also usually a good idea (but not
1333required if you know what you are doing). 1333required if you know what you are doing).
1334 1334
1335If you cannot use non-blocking mode, then force the use of a 1335If you cannot use non-blocking mode, then force the use of a
1336known-to-be-good backend (at the time of this writing, this includes only 1336known-to-be-good backend (at the time of this writing, this includes only
1337C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). 1337C<EVBACKEND_SELECT> and C<EVBACKEND_POLL>). The same applies to file
1338descriptors for which non-blocking operation makes no sense (such as
1339files) - libev doesn't guarentee any specific behaviour in that case.
1338 1340
1339Another thing you have to watch out for is that it is quite easy to 1341Another thing you have to watch out for is that it is quite easy to
1340receive "spurious" readiness notifications, that is your callback might 1342receive "spurious" readiness notifications, that is your callback might
1341be called with C<EV_READ> but a subsequent C<read>(2) will actually block 1343be called with C<EV_READ> but a subsequent C<read>(2) will actually block
1342because there is no data. Not only are some backends known to create a 1344because there is no data. Not only are some backends known to create a
1463year, it will still time out after (roughly) one hour. "Roughly" because 1465year, it will still time out after (roughly) one hour. "Roughly" because
1464detecting time jumps is hard, and some inaccuracies are unavoidable (the 1466detecting time jumps is hard, and some inaccuracies are unavoidable (the
1465monotonic clock option helps a lot here). 1467monotonic clock option helps a lot here).
1466 1468
1467The callback is guaranteed to be invoked only I<after> its timeout has 1469The callback is guaranteed to be invoked only I<after> its timeout has
1468passed. If multiple timers become ready during the same loop iteration 1470passed (not I<at>, so on systems with very low-resolution clocks this
1469then the ones with earlier time-out values are invoked before ones with 1471might introduce a small delay). If multiple timers become ready during the
1472same loop iteration then the ones with earlier time-out values are invoked
1470later time-out values (but this is no longer true when a callback calls 1473before ones with later time-out values (but this is no longer true when a
1471C<ev_loop> recursively). 1474callback calls C<ev_loop> recursively).
1472 1475
1473=head3 Be smart about timeouts 1476=head3 Be smart about timeouts
1474 1477
1475Many real-world problems involve some kind of timeout, usually for error 1478Many real-world problems involve some kind of timeout, usually for error
1476recovery. A typical example is an HTTP request - if the other side hangs, 1479recovery. A typical example is an HTTP request - if the other side hangs,

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines