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

Comparing libev/ev.pod (file contents):
Revision 1.432 by root, Sat Apr 26 14:28:48 2014 UTC vs.
Revision 1.435 by root, Tue Apr 21 10:10:57 2015 UTC

… …
682If you need dynamically allocated loops it is better to use C<ev_loop_new> 682If you need dynamically allocated loops it is better to use C<ev_loop_new>
683and C<ev_loop_destroy>. 683and C<ev_loop_destroy>.
684 684
685=item ev_loop_fork (loop) 685=item ev_loop_fork (loop)
686 686
687This function sets a flag that causes subsequent C<ev_run> iterations to 687This function sets a flag that causes subsequent C<ev_run> iterations
688reinitialise the kernel state for backends that have one. Despite the 688to reinitialise the kernel state for backends that have one. Despite
689name, you can call it anytime, but it makes most sense after forking, in 689the name, you can call it anytime you are allowed to start or stop
690the child process. You I<must> call it (or use C<EVFLAG_FORKCHECK>) in the 690watchers (except inside an C<ev_prepare> callback), but it makes most
691sense after forking, in the child process. You I<must> call it (or use
691child before resuming or calling C<ev_run>. 692C<EVFLAG_FORKCHECK>) in the child before resuming or calling C<ev_run>.
692 693
693Again, you I<have> to call it on I<any> loop that you want to re-use after 694Again, you I<have> to call it on I<any> loop that you want to re-use after
694a fork, I<even if you do not plan to use the loop in the parent>. This is 695a fork, I<even if you do not plan to use the loop in the parent>. This is
695because some kernel interfaces *cough* I<kqueue> *cough* do funny things 696because some kernel interfaces *cough* I<kqueue> *cough* do funny things
696during fork. 697during fork.
… …
2028 2029
2029The relative timeouts are calculated relative to the C<ev_now ()> 2030The relative timeouts are calculated relative to the C<ev_now ()>
2030time. This is usually the right thing as this timestamp refers to the time 2031time. This is usually the right thing as this timestamp refers to the time
2031of the event triggering whatever timeout you are modifying/starting. If 2032of the event triggering whatever timeout you are modifying/starting. If
2032you suspect event processing to be delayed and you I<need> to base the 2033you suspect event processing to be delayed and you I<need> to base the
2033timeout on the current time, use something like this to adjust for this: 2034timeout on the current time, use something like the following to adjust
2035for it:
2034 2036
2035 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); 2037 ev_timer_set (&timer, after + (ev_time () - ev_now ()), 0.);
2036 2038
2037If the event loop is suspended for a long time, you can also force an 2039If the event loop is suspended for a long time, you can also force an
2038update of the time returned by C<ev_now ()> by calling C<ev_now_update 2040update of the time returned by C<ev_now ()> by calling C<ev_now_update
2039()>. 2041()>, although that will push the event time of all outstanding events
2042further into the future.
2040 2043
2041=head3 The special problem of unsynchronised clocks 2044=head3 The special problem of unsynchronised clocks
2042 2045
2043Modern systems have a variety of clocks - libev itself uses the normal 2046Modern systems have a variety of clocks - libev itself uses the normal
2044"wall clock" clock and, if available, the monotonic clock (to avoid time 2047"wall clock" clock and, if available, the monotonic clock (to avoid time
… …
2907 2910
2908Prepare and check watchers are often (but not always) used in pairs: 2911Prepare and check watchers are often (but not always) used in pairs:
2909prepare watchers get invoked before the process blocks and check watchers 2912prepare watchers get invoked before the process blocks and check watchers
2910afterwards. 2913afterwards.
2911 2914
2912You I<must not> call C<ev_run> or similar functions that enter 2915You I<must not> call C<ev_run> (or similar functions that enter the
2913the current event loop from either C<ev_prepare> or C<ev_check> 2916current event loop) or C<ev_loop_fork> from either C<ev_prepare> or
2914watchers. Other loops than the current one are fine, however. The 2917C<ev_check> watchers. Other loops than the current one are fine,
2915rationale behind this is that you do not need to check for recursion in 2918however. The rationale behind this is that you do not need to check
2916those watchers, i.e. the sequence will always be C<ev_prepare>, blocking, 2919for recursion in those watchers, i.e. the sequence will always be
2917C<ev_check> so if you have one watcher of each kind they will always be 2920C<ev_prepare>, blocking, C<ev_check> so if you have one watcher of each
2918called in pairs bracketing the blocking call. 2921kind they will always be called in pairs bracketing the blocking call.
2919 2922
2920Their main purpose is to integrate other event mechanisms into libev and 2923Their main purpose is to integrate other event mechanisms into libev and
2921their use is somewhat advanced. They could be used, for example, to track 2924their use is somewhat advanced. They could be used, for example, to track
2922variable changes, implement your own watchers, integrate net-snmp or a 2925variable changes, implement your own watchers, integrate net-snmp or a
2923coroutine library and lots more. They are also occasionally useful if 2926coroutine library and lots more. They are also occasionally useful if
… …
3263and calls it in the wrong process, the fork handlers will be invoked, too, 3266and calls it in the wrong process, the fork handlers will be invoked, too,
3264of course. 3267of course.
3265 3268
3266=head3 The special problem of life after fork - how is it possible? 3269=head3 The special problem of life after fork - how is it possible?
3267 3270
3268Most uses of C<fork()> consist of forking, then some simple calls to set 3271Most uses of C<fork ()> consist of forking, then some simple calls to set
3269up/change the process environment, followed by a call to C<exec()>. This 3272up/change the process environment, followed by a call to C<exec()>. This
3270sequence should be handled by libev without any problems. 3273sequence should be handled by libev without any problems.
3271 3274
3272This changes when the application actually wants to do event handling 3275This changes when the application actually wants to do event handling
3273in the child, or both parent in child, in effect "continuing" after the 3276in the child, or both parent in child, in effect "continuing" after the
… …
3897To embed libev, see L</EMBEDDING>, but in short, it's easiest to create two 3900To embed libev, see L</EMBEDDING>, but in short, it's easiest to create two
3898files, F<my_ev.h> and F<my_ev.c> that include the respective libev files: 3901files, F<my_ev.h> and F<my_ev.c> that include the respective libev files:
3899 3902
3900 // my_ev.h 3903 // my_ev.h
3901 #define EV_CB_DECLARE(type) struct my_coro *cb; 3904 #define EV_CB_DECLARE(type) struct my_coro *cb;
3902 #define EV_CB_INVOKE(watcher) switch_to ((watcher)->cb); 3905 #define EV_CB_INVOKE(watcher) switch_to ((watcher)->cb)
3903 #include "../libev/ev.h" 3906 #include "../libev/ev.h"
3904 3907
3905 // my_ev.c 3908 // my_ev.c
3906 #define EV_H "my_ev.h" 3909 #define EV_H "my_ev.h"
3907 #include "../libev/ev.c" 3910 #include "../libev/ev.c"

Diff Legend

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