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