ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.255 by root, Tue Jul 14 19:11:31 2009 UTC vs.
Revision 1.257 by root, Wed Jul 15 16:08:24 2009 UTC

… …
862 862
863This call will simply invoke all pending watchers while resetting their 863This call will simply invoke all pending watchers while resetting their
864pending state. Normally, C<ev_loop> does this automatically when required, 864pending state. Normally, C<ev_loop> does this automatically when required,
865but when overriding the invoke callback this call comes handy. 865but when overriding the invoke callback this call comes handy.
866 866
867=item int ev_pending_count (loop)
868
869Returns the number of pending watchers - zero indicates that no watchers
870are pending.
871
867=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P)) 872=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P))
868 873
869This overrides the invoke pending functionality of the loop: Instead of 874This overrides the invoke pending functionality of the loop: Instead of
870invoking all pending watchers when there are any, C<ev_loop> will call 875invoking all pending watchers when there are any, C<ev_loop> will call
871this callback instead. This is useful, for example, when you want to 876this callback instead. This is useful, for example, when you want to
… …
1750 1755
1751If the event loop is suspended for a long time, you can also force an 1756If the event loop is suspended for a long time, you can also force an
1752update of the time returned by C<ev_now ()> by calling C<ev_now_update 1757update of the time returned by C<ev_now ()> by calling C<ev_now_update
1753()>. 1758()>.
1754 1759
1760=head3 The special problems of suspended animation
1761
1762When you leave the server world it is quite customary to hit machines that
1763can suspend/hibernate - what happens to the clocks during such a suspend?
1764
1765Some quick tests made with a Linux 2.6.28 indicate that a suspend freezes
1766all processes, while the clocks (C<times>, C<CLOCK_MONOTONIC>) continue
1767to run until the system is suspended, but they will not advance while the
1768system is suspended. That means, on resume, it will be as if the program
1769was frozen for a few seconds, but the suspend time will not be counted
1770towards C<ev_timer> when a monotonic clock source is used. The real time
1771clock advanced as expected, but if it is used as sole clocksource, then a
1772long suspend would be detected as a time jump by libev, and timers would
1773be adjusted accordingly.
1774
1775I would not be surprised to see different behaviour in different between
1776operating systems, OS versions or even different hardware.
1777
1778The other form of suspend (job control, or sending a SIGSTOP) will see a
1779time jump in the monotonic clocks and the realtime clock. If the program
1780is suspended for a very long time, and monotonic clock sources are in use,
1781then you can expect C<ev_timer>s to expire as the full suspension time
1782will be counted towards the timers. When no monotonic clock source is in
1783use, then libev will again assume a timejump and adjust accordingly.
1784
1785It might be beneficial for this latter case to call C<ev_suspend>
1786and C<ev_resume> in code that handles C<SIGTSTP>, to at least get
1787deterministic behaviour in this case (you can do nothing against
1788C<SIGSTOP>).
1789
1755=head3 Watcher-Specific Functions and Data Members 1790=head3 Watcher-Specific Functions and Data Members
1756 1791
1757=over 4 1792=over 4
1758 1793
1759=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat) 1794=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
… …
4028 } 4063 }
4029 4064
4030Instead of invoking all pending watchers, the C<l_invoke> callback will 4065Instead of invoking all pending watchers, the C<l_invoke> callback will
4031signal the main thread via some unspecified mechanism (signals? pipe 4066signal the main thread via some unspecified mechanism (signals? pipe
4032writes? C<Async::Interrupt>?) and then waits until all pending watchers 4067writes? C<Async::Interrupt>?) and then waits until all pending watchers
4033have been called: 4068have been called (in a while loop because a) spurious wakeups are possible
4069and b) skipping inter-thread-communication when there are no pending
4070watchers is very beneficial):
4034 4071
4035 static void 4072 static void
4036 l_invoke (EV_P) 4073 l_invoke (EV_P)
4037 { 4074 {
4038 userdata *u = ev_userdata (EV_A); 4075 userdata *u = ev_userdata (EV_A);
4039 4076
4077 while (ev_pending_count (EV_A))
4078 {
4040 wake_up_other_thread_in_some_magic_or_not_so_magic_way (); 4079 wake_up_other_thread_in_some_magic_or_not_so_magic_way ();
4041
4042 pthread_cond_wait (&u->invoke_cv, &u->lock); 4080 pthread_cond_wait (&u->invoke_cv, &u->lock);
4081 }
4043 } 4082 }
4044 4083
4045Now, whenever the main thread gets told to invoke pending watchers, it 4084Now, whenever the main thread gets told to invoke pending watchers, it
4046will grab the lock, call C<ev_invoke_pending> and then signal the loop 4085will grab the lock, call C<ev_invoke_pending> and then signal the loop
4047thread to continue: 4086thread to continue:

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines