summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorroot <root>2007-12-09 19:42:57 +0000
committerroot <root>2007-12-09 19:42:57 +0000
commit5466167e0504f6fd929074dda89e770d4abfd3c3 (patch)
treef46d6c47f087b39c5cba31915c358e14232d70cb
parent50e0437d43c557d055e311d627eb167756315b91 (diff)
*** empty log message ***
-rw-r--r--ev.html30
-rw-r--r--ev.pod30
2 files changed, 41 insertions, 19 deletions
diff --git a/ev.html b/ev.html
index da28682..308d179 100644
--- a/ev.html
+++ b/ev.html
@@ -6,7 +6,7 @@
<meta name="description" content="Pod documentation for libev" />
<meta name="inputfile" content="&lt;standard input&gt;" />
<meta name="outputfile" content="&lt;standard output&gt;" />
- <meta name="created" content="Sat Dec 8 23:11:11 2007" />
+ <meta name="created" content="Sun Dec 9 20:30:11 2007" />
<meta name="generator" content="Pod::Xhtml 1.57" />
<link rel="stylesheet" href="http://res.tst.eu/pod.css"/></head>
<body>
@@ -1099,10 +1099,10 @@ to trigger &quot;at&quot; some specific point in time. For example, if you tell
periodic watcher to trigger in 10 seconds (by specifiying e.g. <code>ev_now ()
+ 10.</code>) and then reset your system clock to the last year, then it will
take a year to trigger the event (unlike an <code>ev_timer</code>, which would trigger
-roughly 10 seconds later and of course not if you reset your system time
-again).</p>
+roughly 10 seconds later).</p>
<p>They can also be used to implement vastly more complex timers, such as
-triggering an event on eahc midnight, local time.</p>
+triggering an event on each midnight, local time or other, complicated,
+rules.</p>
<p>As with timers, the callback is guarenteed to be invoked only when the
time (<code>at</code>) has been passed, but if multiple periodic timers become ready
during the same loop iteration then order of execution is undefined.</p>
@@ -1114,18 +1114,18 @@ during the same loop iteration then order of execution is undefined.</p>
operation, and we will explain them from simplest to complex:</p>
<p>
<dl>
- <dt>* absolute timer (interval = reschedule_cb = 0)</dt>
+ <dt>* absolute timer (at = time, interval = reschedule_cb = 0)</dt>
<dd>
<p>In this configuration the watcher triggers an event at the wallclock time
<code>at</code> and doesn't repeat. It will not adjust when a time jump occurs,
that is, if it is to be run at January 1st 2011 then it will run when the
system time reaches or surpasses this time.</p>
</dd>
- <dt>* non-repeating interval timer (interval &gt; 0, reschedule_cb = 0)</dt>
+ <dt>* non-repeating interval timer (at = offset, interval &gt; 0, reschedule_cb = 0)</dt>
<dd>
<p>In this mode the watcher will always be scheduled to time out at the next
-<code>at + N * interval</code> time (for some integer N) and then repeat, regardless
-of any time jumps.</p>
+<code>at + N * interval</code> time (for some integer N, which can also be negative)
+and then repeat, regardless of any time jumps.</p>
<p>This can be used to create timers that do not drift with respect to system
time:</p>
<pre> ev_periodic_set (&amp;periodic, 0., 3600., 0);
@@ -1138,8 +1138,11 @@ by 3600.</p>
<p>Another way to think about it (for the mathematically inclined) is that
<code>ev_periodic</code> will try to run the callback in this mode at the next possible
time where <code>time = at (mod interval)</code>, regardless of any time jumps.</p>
+ <p>For numerical stability it is preferable that the <code>at</code> value is near
+<code>ev_now ()</code> (the current time), but there is no range requirement for
+this value.</p>
</dd>
- <dt>* manual reschedule mode (reschedule_cb = callback)</dt>
+ <dt>* manual reschedule mode (at and interval ignored, reschedule_cb = callback)</dt>
<dd>
<p>In this mode the values for <code>interval</code> and <code>at</code> are both being
ignored. Instead, each time the periodic watcher gets scheduled, the
@@ -1148,7 +1151,7 @@ current time as second argument.</p>
<p>NOTE: <i>This callback MUST NOT stop or destroy any periodic watcher,
ever, or make any event loop modifications</i>. If you need to stop it,
return <code>now + 1e30</code> (or so, fudge fudge) and stop it afterwards (e.g. by
-starting a prepare watcher).</p>
+starting an <code>ev_prepare</code> watcher, which is legal).</p>
<p>Its prototype is <code>ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
ev_tstamp now)</code>, e.g.:</p>
<pre> static ev_tstamp my_rescheduler (struct ev_periodic *w, ev_tstamp now)
@@ -1179,6 +1182,13 @@ when you changed some parameters or the reschedule callback would return
a different time than the last time it was called (e.g. in a crond like
program when the crontabs have changed).</p>
</dd>
+ <dt>ev_tstamp offset [read-write]</dt>
+ <dd>
+ <p>When repeating, this contains the offset value, otherwise this is the
+absolute point in time (the <code>at</code> value passed to <code>ev_periodic_set</code>).</p>
+ <p>Can be modified any time, but changes only take effect when the periodic
+timer fires or <code>ev_periodic_again</code> is being called.</p>
+ </dd>
<dt>ev_tstamp interval [read-write]</dt>
<dd>
<p>The current interval value. Can be modified any time, but changes only
diff --git a/ev.pod b/ev.pod
index 237bdb0..3ad52c0 100644
--- a/ev.pod
+++ b/ev.pod
@@ -1076,11 +1076,11 @@ to trigger "at" some specific point in time. For example, if you tell a
periodic watcher to trigger in 10 seconds (by specifiying e.g. C<ev_now ()
+ 10.>) and then reset your system clock to the last year, then it will
take a year to trigger the event (unlike an C<ev_timer>, which would trigger
-roughly 10 seconds later and of course not if you reset your system time
-again).
+roughly 10 seconds later).
They can also be used to implement vastly more complex timers, such as
-triggering an event on eahc midnight, local time.
+triggering an event on each midnight, local time or other, complicated,
+rules.
As with timers, the callback is guarenteed to be invoked only when the
time (C<at>) has been passed, but if multiple periodic timers become ready
@@ -1097,18 +1097,18 @@ operation, and we will explain them from simplest to complex:
=over 4
-=item * absolute timer (interval = reschedule_cb = 0)
+=item * absolute timer (at = time, interval = reschedule_cb = 0)
In this configuration the watcher triggers an event at the wallclock time
C<at> and doesn't repeat. It will not adjust when a time jump occurs,
that is, if it is to be run at January 1st 2011 then it will run when the
system time reaches or surpasses this time.
-=item * non-repeating interval timer (interval > 0, reschedule_cb = 0)
+=item * non-repeating interval timer (at = offset, interval > 0, reschedule_cb = 0)
In this mode the watcher will always be scheduled to time out at the next
-C<at + N * interval> time (for some integer N) and then repeat, regardless
-of any time jumps.
+C<at + N * interval> time (for some integer N, which can also be negative)
+and then repeat, regardless of any time jumps.
This can be used to create timers that do not drift with respect to system
time:
@@ -1124,7 +1124,11 @@ Another way to think about it (for the mathematically inclined) is that
C<ev_periodic> will try to run the callback in this mode at the next possible
time where C<time = at (mod interval)>, regardless of any time jumps.
-=item * manual reschedule mode (reschedule_cb = callback)
+For numerical stability it is preferable that the C<at> value is near
+C<ev_now ()> (the current time), but there is no range requirement for
+this value.
+
+=item * manual reschedule mode (at and interval ignored, reschedule_cb = callback)
In this mode the values for C<interval> and C<at> are both being
ignored. Instead, each time the periodic watcher gets scheduled, the
@@ -1134,7 +1138,7 @@ current time as second argument.
NOTE: I<This callback MUST NOT stop or destroy any periodic watcher,
ever, or make any event loop modifications>. If you need to stop it,
return C<now + 1e30> (or so, fudge fudge) and stop it afterwards (e.g. by
-starting a prepare watcher).
+starting an C<ev_prepare> watcher, which is legal).
Its prototype is C<ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
ev_tstamp now)>, e.g.:
@@ -1167,6 +1171,14 @@ when you changed some parameters or the reschedule callback would return
a different time than the last time it was called (e.g. in a crond like
program when the crontabs have changed).
+=item ev_tstamp offset [read-write]
+
+When repeating, this contains the offset value, otherwise this is the
+absolute point in time (the C<at> value passed to C<ev_periodic_set>).
+
+Can be modified any time, but changes only take effect when the periodic
+timer fires or C<ev_periodic_again> is being called.
+
=item ev_tstamp interval [read-write]
The current interval value. Can be modified any time, but changes only