summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorroot <root>2009-07-15 16:08:24 +0000
committerroot <root>2009-07-15 16:08:24 +0000
commit2978dc2e820ccb62fe7f3b35a0672455e592017e (patch)
treec46918d0f6f4d207b93a637e2a2a969948105f01
parent5fda87c6986d7a734b73b21afac13eb80242012b (diff)
*** empty log message ***
-rw-r--r--Changes1
-rw-r--r--ev.pod30
2 files changed, 31 insertions, 0 deletions
diff --git a/Changes b/Changes
index 7b82911..a7df7ff 100644
--- a/Changes
+++ b/Changes
@@ -25,6 +25,7 @@ TODO: EV_MINIMAL
- do not compile in any priority code when EV_MAXPRI == EV_MINPRI.
- support EV_MINIMAL==2 for a reduced API.
- actually 0-initialise struct sigaction when installing signals.
+ - add section on hibernate and stopped processes to ev_timer docs.
3.6 Tue Apr 28 02:49:30 CEST 2009
- multiple timers becoming ready within an event loop iteration
diff --git a/ev.pod b/ev.pod
index ec747e8..feabbcc 100644
--- a/ev.pod
+++ b/ev.pod
@@ -1757,6 +1757,36 @@ If the event loop is suspended for a long time, you can also force an
update of the time returned by C<ev_now ()> by calling C<ev_now_update
()>.
+=head3 The special problems of suspended animation
+
+When you leave the server world it is quite customary to hit machines that
+can suspend/hibernate - what happens to the clocks during such a suspend?
+
+Some quick tests made with a Linux 2.6.28 indicate that a suspend freezes
+all processes, while the clocks (C<times>, C<CLOCK_MONOTONIC>) continue
+to run until the system is suspended, but they will not advance while the
+system is suspended. That means, on resume, it will be as if the program
+was frozen for a few seconds, but the suspend time will not be counted
+towards C<ev_timer> when a monotonic clock source is used. The real time
+clock advanced as expected, but if it is used as sole clocksource, then a
+long suspend would be detected as a time jump by libev, and timers would
+be adjusted accordingly.
+
+I would not be surprised to see different behaviour in different between
+operating systems, OS versions or even different hardware.
+
+The other form of suspend (job control, or sending a SIGSTOP) will see a
+time jump in the monotonic clocks and the realtime clock. If the program
+is suspended for a very long time, and monotonic clock sources are in use,
+then you can expect C<ev_timer>s to expire as the full suspension time
+will be counted towards the timers. When no monotonic clock source is in
+use, then libev will again assume a timejump and adjust accordingly.
+
+It might be beneficial for this latter case to call C<ev_suspend>
+and C<ev_resume> in code that handles C<SIGTSTP>, to at least get
+deterministic behaviour in this case (you can do nothing against
+C<SIGSTOP>).
+
=head3 Watcher-Specific Functions and Data Members
=over 4