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

Comparing libev/ev.pod (file contents):
Revision 1.175 by root, Mon Sep 8 16:36:14 2008 UTC vs.
Revision 1.178 by root, Sat Sep 13 18:25:50 2008 UTC

572Returns the current "event loop time", which is the time the event loop 572Returns the current "event loop time", which is the time the event loop
573received events and started processing them. This timestamp does not 573received events and started processing them. This timestamp does not
574change as long as callbacks are being processed, and this is also the base 574change as long as callbacks are being processed, and this is also the base
575time used for relative timers. You can treat it as the timestamp of the 575time used for relative timers. You can treat it as the timestamp of the
576event occurring (or more correctly, libev finding out about it). 576event occurring (or more correctly, libev finding out about it).
577
578=item ev_now_update (loop)
579
580Establishes the current time by querying the kernel, updating the time
581returned by C<ev_now ()> in the progress. This is a costly operation and
582is usually done automatically within C<ev_loop ()>.
583
584This function is rarely useful, but when some event callback runs for a
585very long time without entering the event loop, updating libev's idea of
586the current time is a good idea.
587
588See also "The special problem of time updates" in the C<ev_timer> section.
577 589
578=item ev_loop (loop, int flags) 590=item ev_loop (loop, int flags)
579 591
580Finally, this is it, the event handler. This function usually is called 592Finally, this is it, the event handler. This function usually is called
581after you initialised all your watchers and you want to start handling 593after you initialised all your watchers and you want to start handling
994 { 1006 {
995 struct ev_io io; 1007 struct ev_io io;
996 int otherfd; 1008 int otherfd;
997 void *somedata; 1009 void *somedata;
998 struct whatever *mostinteresting; 1010 struct whatever *mostinteresting;
999 } 1011 };
1012
1013 ...
1014 struct my_io w;
1015 ev_io_init (&w.io, my_cb, fd, EV_READ);
1000 1016
1001And since your callback will be called with a pointer to the watcher, you 1017And since your callback will be called with a pointer to the watcher, you
1002can cast it back to your own type: 1018can cast it back to your own type:
1003 1019
1004 static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents) 1020 static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents)
1008 } 1024 }
1009 1025
1010More interesting and less C-conformant ways of casting your callback type 1026More interesting and less C-conformant ways of casting your callback type
1011instead have been omitted. 1027instead have been omitted.
1012 1028
1013Another common scenario is having some data structure with multiple 1029Another common scenario is to use some data structure with multiple
1014watchers: 1030embedded watchers:
1015 1031
1016 struct my_biggy 1032 struct my_biggy
1017 { 1033 {
1018 int some_data; 1034 int some_data;
1019 ev_timer t1; 1035 ev_timer t1;
1020 ev_timer t2; 1036 ev_timer t2;
1021 } 1037 }
1022 1038
1023In this case getting the pointer to C<my_biggy> is a bit more complicated, 1039In this case getting the pointer to C<my_biggy> is a bit more
1024you need to use C<offsetof>: 1040complicated: Either you store the address of your C<my_biggy> struct
1041in the C<data> member of the watcher, or you need to use some pointer
1042arithmetic using C<offsetof> inside your watchers:
1025 1043
1026 #include <stddef.h> 1044 #include <stddef.h>
1027 1045
1028 static void 1046 static void
1029 t1_cb (EV_P_ struct ev_timer *w, int revents) 1047 t1_cb (EV_P_ struct ev_timer *w, int revents)
1203but if multiple timers become ready during the same loop iteration then 1221but if multiple timers become ready during the same loop iteration then
1204order of execution is undefined. 1222order of execution is undefined.
1205 1223
1206=head3 The special problem of time updates 1224=head3 The special problem of time updates
1207 1225
1208Requesting the current time is a costly operation (it usually takes at 1226Establishing the current time is a costly operation (it usually takes at
1209least two syscalls): EV therefore updates it's idea of the current time 1227least two system calls): EV therefore updates its idea of the current
1210only before and after C<ev_loop> polls for new events, which causes the 1228time only before and after C<ev_loop> polls for new events, which causes
1211difference between C<ev_now ()> and C<ev_time ()>. 1229a growing difference between C<ev_now ()> and C<ev_time ()> when handling
1230lots of events.
1212 1231
1213The relative timeouts are calculated relative to the C<ev_now ()> 1232The relative timeouts are calculated relative to the C<ev_now ()>
1214time. This is usually the right thing as this timestamp refers to the time 1233time. This is usually the right thing as this timestamp refers to the time
1215of the event triggering whatever timeout you are modifying/starting. If 1234of the event triggering whatever timeout you are modifying/starting. If
1216you suspect event processing to be delayed and you I<need> to base the 1235you suspect event processing to be delayed and you I<need> to base the
1217timeout on the current time, use something like this to adjust for this: 1236timeout on the current time, use something like this to adjust for this:
1218 1237
1219 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); 1238 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
1239
1240If the event loop is suspended for a long time, you can also force an
1241update of the time returned by C<ev_now ()> by calling C<ev_now_update
1242()>.
1220 1243
1221=head3 Watcher-Specific Functions and Data Members 1244=head3 Watcher-Specific Functions and Data Members
1222 1245
1223=over 4 1246=over 4
1224 1247

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines