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

Comparing libev/ev.pod (file contents):
Revision 1.248 by root, Wed Jul 8 04:14:34 2009 UTC vs.
Revision 1.253 by root, Tue Jul 14 18:33:48 2009 UTC

… …
856more often than 100 times per second: 856more often than 100 times per second:
857 857
858 ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1); 858 ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1);
859 ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01); 859 ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);
860 860
861=item ev_invoke_pending (loop)
862
863This call will simply invoke all pending watchers while resetting their
864pending state. Normally, C<ev_loop> does this automatically when required,
865but when overriding the invoke callback this call comes handy.
866
867=item ev_set_invoke_pending_cb (loop, void (*invoke_pending_cb)(EV_P))
868
869This overrides the invoke pending functionality of the loop: Instead of
870invoking all pending watchers when there are any, C<ev_loop> will call
871this callback instead. This is useful, for example, when you want to
872invoke the actual watchers inside another context (another thread etc.).
873
874If you want to reset the callback, use C<ev_invoke_pending> as new
875callback.
876
877=item ev_set_loop_release_cb (loop, void (*release)(EV_P), void (*acquire)(EV_P))
878
879Sometimes you want to share the same loop between multiple threads. This
880can be done relatively simply by putting mutex_lock/unlock calls around
881each call to a libev function.
882
883However, C<ev_loop> can run an indefinite time, so it is not feasible to
884wait for it to return. One way around this is to wake up the loop via
885C<ev_unloop> and C<av_async_send>, another way is to set these I<release>
886and I<acquire> callbacks on the loop.
887
888When set, then C<release> will be called just before the thread is
889suspended waiting for new events, and C<acquire> is called just
890afterwards.
891
892Ideally, C<release> will just call your mutex_unlock function, and
893C<acquire> will just call the mutex_lock function again.
894
895=item ev_set_userdata (loop, void *data)
896
897=item ev_userdata (loop)
898
899Set and retrieve a single C<void *> associated with a loop. When
900C<ev_set_userdata> has never been called, then C<ev_userdata> returns
901C<0.>
902
903These two functions can be used to associate arbitrary data with a loop,
904and are intended solely for the C<invoke_pending_cb>, C<release> and
905C<acquire> callbacks described above, but of course can be (ab-)used for
906any other purpose as well.
907
861=item ev_loop_verify (loop) 908=item ev_loop_verify (loop)
862 909
863This function only does something when C<EV_VERIFY> support has been 910This function only does something when C<EV_VERIFY> support has been
864compiled in, which is the default for non-minimal builds. It tries to go 911compiled in, which is the default for non-minimal builds. It tries to go
865through all internal structures and checks them for validity. If anything 912through all internal structures and checks them for validity. If anything
… …
2033 2080
2034Only the default event loop is capable of handling signals, and therefore 2081Only the default event loop is capable of handling signals, and therefore
2035you can only register child watchers in the default event loop. 2082you can only register child watchers in the default event loop.
2036 2083
2037Due to some design glitches inside libev, child watchers will always be 2084Due to some design glitches inside libev, child watchers will always be
2038handled at maximum priority (their priority is set to EV_MAXPRI by libev) 2085handled at maximum priority (their priority is set to C<EV_MAXPRI> by
2086libev)
2039 2087
2040=head3 Process Interaction 2088=head3 Process Interaction
2041 2089
2042Libev grabs C<SIGCHLD> as soon as the default event loop is 2090Libev grabs C<SIGCHLD> as soon as the default event loop is
2043initialised. This is necessary to guarantee proper behaviour even if 2091initialised. This is necessary to guarantee proper behaviour even if
… …
3670defined to be C<0>, then they are not. 3718defined to be C<0>, then they are not.
3671 3719
3672=item EV_MINIMAL 3720=item EV_MINIMAL
3673 3721
3674If you need to shave off some kilobytes of code at the expense of some 3722If you need to shave off some kilobytes of code at the expense of some
3675speed, define this symbol to C<1>. Currently this is used to override some 3723speed (but with the full API), define this symbol to C<1>. Currently this
3676inlining decisions, saves roughly 30% code size on amd64. It also selects a 3724is used to override some inlining decisions, saves roughly 30% code size
3677much smaller 2-heap for timer management over the default 4-heap. 3725on amd64. It also selects a much smaller 2-heap for timer management over
3726the default 4-heap.
3727
3728You can save even more by disabling watcher types you do not need
3729and setting C<EV_MAXPRI> == C<EV_MINPRI>. Also, disabling C<assert>
3730(C<-DNDEBUG>) will usually reduce code size a lot.
3731
3732Defining C<EV_MINIMAL> to C<2> will additionally reduce the core API to
3733provide a bare-bones event library. See C<ev.h> for details on what parts
3734of the API are still available, and do not complain if this subset changes
3735over time.
3678 3736
3679=item EV_PID_HASHSIZE 3737=item EV_PID_HASHSIZE
3680 3738
3681C<ev_child> watchers use a small hash table to distribute workload by 3739C<ev_child> watchers use a small hash table to distribute workload by
3682pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more 3740pid. The default size is C<16> (or C<1> with C<EV_MINIMAL>), usually more
… …
3868default loop and triggering an C<ev_async> watcher from the default loop 3926default loop and triggering an C<ev_async> watcher from the default loop
3869watcher callback into the event loop interested in the signal. 3927watcher callback into the event loop interested in the signal.
3870 3928
3871=back 3929=back
3872 3930
3931=head4 THREAD LOCKING EXAMPLE
3932
3873=head3 COROUTINES 3933=head3 COROUTINES
3874 3934
3875Libev is very accommodating to coroutines ("cooperative threads"): 3935Libev is very accommodating to coroutines ("cooperative threads"):
3876libev fully supports nesting calls to its functions from different 3936libev fully supports nesting calls to its functions from different
3877coroutines (e.g. you can call C<ev_loop> on the same loop from two 3937coroutines (e.g. you can call C<ev_loop> on the same loop from two

Diff Legend

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