*** empty log message ***

Marc Alexander Lehmann 2009-07-15 16:08:24 +00:00
parent 106b30a588
commit c18d2be587
2 changed files with 31 additions and 0 deletions

View File

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

View File

@ -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
=head3 Watcher-Specific Functions and Data Members
=over 4