| … | |
… | |
| 243 | |
243 | |
| 244 | This returns the "current wallclock time" as a fractional number of |
244 | This returns the "current wallclock time" as a fractional number of |
| 245 | seconds since the Epoch (the same thing as C<time> or C<Time::HiRes::time> |
245 | seconds since the Epoch (the same thing as C<time> or C<Time::HiRes::time> |
| 246 | return, and the result is guaranteed to be compatible with those). |
246 | return, and the result is guaranteed to be compatible with those). |
| 247 | |
247 | |
| 248 | It progresses independently of any event loop processing. |
248 | It progresses independently of any event loop processing, i.e. each call |
| 249 | |
249 | will check the system clock, which usually gets updated frequently. |
| 250 | In almost all cases (in all cases if you don't care), this is the function |
|
|
| 251 | to call when you want to know the current time. |
|
|
| 252 | |
250 | |
| 253 | =item AnyEvent->now |
251 | =item AnyEvent->now |
| 254 | |
252 | |
| 255 | This also returns the "current wallclock time", but unlike C<time>, above, |
253 | This also returns the "current wallclock time", but unlike C<time>, above, |
| 256 | this value might change only once per event loop iteration, depending on |
254 | this value might change only once per event loop iteration, depending on |
| 257 | the event loop (most return the same time as C<time>, above). This is the |
255 | the event loop (most return the same time as C<time>, above). This is the |
| 258 | time that AnyEvent timers get scheduled against. |
256 | time that AnyEvent's timers get scheduled against. |
|
|
257 | |
|
|
258 | I<In almost all cases (in all cases if you don't care), this is the |
|
|
259 | function to call when you want to know the current time.> |
|
|
260 | |
|
|
261 | This function is also often faster then C<< AnyEvent->time >>, and |
|
|
262 | thus the preferred method if you want some timestamp (for example, |
|
|
263 | L<AnyEvent::Handle> uses this to update it's activity timeouts). |
|
|
264 | |
|
|
265 | The rest of this section is only of relevance if you try to be very exact |
|
|
266 | with your timing, you can skip it without bad conscience. |
| 259 | |
267 | |
| 260 | For a practical example of when these times differ, consider L<Event::Lib> |
268 | For a practical example of when these times differ, consider L<Event::Lib> |
| 261 | and L<EV> and the following set-up: |
269 | and L<EV> and the following set-up: |
| 262 | |
270 | |
| 263 | The event loop is running and has just invoked one of your callback at |
271 | The event loop is running and has just invoked one of your callback at |
| … | |
… | |
| 268 | |
276 | |
| 269 | With L<Event::Lib>, C<< AnyEvent->time >> and C<< AnyEvent->now >> will |
277 | With L<Event::Lib>, C<< AnyEvent->time >> and C<< AnyEvent->now >> will |
| 270 | both return C<501>, because that is the current time, and the timer will |
278 | both return C<501>, because that is the current time, and the timer will |
| 271 | be scheduled to fire at time=504 (C<501> + C<3>). |
279 | be scheduled to fire at time=504 (C<501> + C<3>). |
| 272 | |
280 | |
| 273 | With L<EV>m C<< AnyEvent->time >> returns C<501> (as that is the current |
281 | With L<EV>, C<< AnyEvent->time >> returns C<501> (as that is the current |
| 274 | time), but C<< AnyEvent->now >> returns C<500>, as that is the time the |
282 | time), but C<< AnyEvent->now >> returns C<500>, as that is the time the |
| 275 | last event processing phase started. With L<EV>, your timer gets scheduled |
283 | last event processing phase started. With L<EV>, your timer gets scheduled |
| 276 | to run at time=503 (C<500> + C<3>). |
284 | to run at time=503 (C<500> + C<3>). |
| 277 | |
285 | |
| 278 | In one sense, L<Event::Lib> is more exact, as it uses the current time |
286 | In one sense, L<Event::Lib> is more exact, as it uses the current time |
| 279 | regardless of any delays introduced by event processing. However, most |
287 | regardless of any delays introduced by event processing. However, most |
| 280 | callbacks do not expect large delays in processing, so this causes a |
288 | callbacks do not expect large delays in processing, so this causes a |
| 281 | higher drift (and a lot more syscalls to get the current time). |
289 | higher drift (and a lot more system calls to get the current time). |
| 282 | |
290 | |
| 283 | In another sense, L<EV> is more exact, as your timer will be scheduled at |
291 | In another sense, L<EV> is more exact, as your timer will be scheduled at |
| 284 | the same time, regardless of how long event processing actually took. |
292 | the same time, regardless of how long event processing actually took. |
| 285 | |
293 | |
| 286 | In either case, if you care (and in most cases, you don't), then you |
294 | In either case, if you care (and in most cases, you don't), then you |
