mirror of /home/gitosis/repositories/libev.git
*** empty log message ***
This commit is contained in:
parent
6a60e9f7b6
commit
f6718ae94b
66
ev.pod
66
ev.pod
|
@ -65,7 +65,7 @@ C<ev_version_minor>. If you want, you can compare against the global
|
|||
symbols C<EV_VERSION_MAJOR> and C<EV_VERSION_MINOR>, which specify the
|
||||
version of the library your program was compiled against.
|
||||
|
||||
Usually, its a good idea to terminate if the major versions mismatch,
|
||||
Usually, it's a good idea to terminate if the major versions mismatch,
|
||||
as this indicates an incompatible change. Minor versions are usually
|
||||
compatible to older versions, so a larger minor version alone is usually
|
||||
not a problem.
|
||||
|
@ -105,7 +105,7 @@ in your main thread (or in a separate thrad) and for each thread you
|
|||
create, you also create another event loop. Libev itself does no locking
|
||||
whatsoever, so if you mix calls to the same event loop in different
|
||||
threads, make sure you lock (this is usually a bad idea, though, even if
|
||||
done correctly, because its hideous and inefficient).
|
||||
done correctly, because it's hideous and inefficient).
|
||||
|
||||
=over 4
|
||||
|
||||
|
@ -128,7 +128,7 @@ It supports the following flags:
|
|||
|
||||
=item EVFLAG_AUTO
|
||||
|
||||
The default flags value. Use this if you have no clue (its the right
|
||||
The default flags value. Use this if you have no clue (it's the right
|
||||
thing, believe me).
|
||||
|
||||
=item EVFLAG_NOENV
|
||||
|
@ -140,17 +140,17 @@ override the flags completely if it is found in the environment. This is
|
|||
useful to try out specific backends to test their performance, or to work
|
||||
around bugs.
|
||||
|
||||
=item EVMETHOD_SELECT portable select backend
|
||||
=item EVMETHOD_SELECT (portable select backend)
|
||||
|
||||
=item EVMETHOD_POLL poll backend (everywhere except windows)
|
||||
=item EVMETHOD_POLL (poll backend, available everywhere except on windows)
|
||||
|
||||
=item EVMETHOD_EPOLL linux only
|
||||
=item EVMETHOD_EPOLL (linux only)
|
||||
|
||||
=item EVMETHOD_KQUEUE some bsds only
|
||||
=item EVMETHOD_KQUEUE (some bsds only)
|
||||
|
||||
=item EVMETHOD_DEVPOLL solaris 8 only
|
||||
=item EVMETHOD_DEVPOLL (solaris 8 only)
|
||||
|
||||
=item EVMETHOD_PORT solaris 10 only
|
||||
=item EVMETHOD_PORT (solaris 10 only)
|
||||
|
||||
If one or more of these are ored into the flags value, then only these
|
||||
backends will be tried (in the reverse order as given here). If one are
|
||||
|
@ -169,7 +169,7 @@ undefined behaviour (or a failed assertion if assertions are enabled).
|
|||
|
||||
Destroys the default loop again (frees all memory and kernel state
|
||||
etc.). This stops all registered event watchers (by not touching them in
|
||||
any way whatsoever, although you cnanot rely on this :).
|
||||
any way whatsoever, although you cannot rely on this :).
|
||||
|
||||
=item ev_loop_destroy (loop)
|
||||
|
||||
|
@ -187,7 +187,7 @@ You I<must> call this function after forking if and only if you want to
|
|||
use the event library in both processes. If you just fork+exec, you don't
|
||||
have to call it.
|
||||
|
||||
The function itself is quite fast and its usually not a problem to call
|
||||
The function itself is quite fast and it's usually not a problem to call
|
||||
it just in case after a fork. To make this easy, the function will fit in
|
||||
quite nicely into a call to C<pthread_atfork>:
|
||||
|
||||
|
@ -204,7 +204,7 @@ after fork, and how you do this is entirely your own problem.
|
|||
Returns one of the C<EVMETHOD_*> flags indicating the event backend in
|
||||
use.
|
||||
|
||||
=item ev_tstamp = ev_now (loop)
|
||||
=item ev_tstamp ev_now (loop)
|
||||
|
||||
Returns the current "event loop time", which is the time the event loop
|
||||
got events and started processing them. This timestamp does not change
|
||||
|
@ -223,11 +223,12 @@ no event watchers are active anymore or C<ev_unloop> was called.
|
|||
|
||||
A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle
|
||||
those events and any outstanding ones, but will not block your process in
|
||||
case there are no events.
|
||||
case there are no events and will return after one iteration of the loop.
|
||||
|
||||
A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if
|
||||
neccessary) and will handle those and any outstanding ones. It will block
|
||||
your process until at least one new event arrives.
|
||||
your process until at least one new event arrives, and will return after
|
||||
one iteration of the loop.
|
||||
|
||||
This flags value could be used to implement alternative looping
|
||||
constructs, but the C<prepare> and C<check> watchers provide a better and
|
||||
|
@ -235,24 +236,25 @@ more generic mechanism.
|
|||
|
||||
=item ev_unloop (loop, how)
|
||||
|
||||
Can be used to make a call to C<ev_loop> return early. The C<how> argument
|
||||
must be either C<EVUNLOOP_ONCE>, which will make the innermost C<ev_loop>
|
||||
call return, or C<EVUNLOOP_ALL>, which will make all nested C<ev_loop>
|
||||
calls return.
|
||||
Can be used to make a call to C<ev_loop> return early (but only after it
|
||||
has processed all outstanding events). The C<how> argument must be either
|
||||
C<EVUNLOOP_ONCE>, which will make the innermost C<ev_loop> call return, or
|
||||
C<EVUNLOOP_ALL>, which will make all nested C<ev_loop> calls return.
|
||||
|
||||
=item ev_ref (loop)
|
||||
|
||||
=item ev_unref (loop)
|
||||
|
||||
Ref/unref can be used to add or remove a refcount on the event loop: Every
|
||||
watcher keeps one reference. If you have a long-runing watcher you never
|
||||
unregister that should not keep ev_loop from running, ev_unref() after
|
||||
starting, and ev_ref() before stopping it. Libev itself uses this for
|
||||
example for its internal signal pipe: It is not visible to you as a user
|
||||
and should not keep C<ev_loop> from exiting if the work is done. It is
|
||||
also an excellent way to do this for generic recurring timers or from
|
||||
within third-party libraries. Just remember to unref after start and ref
|
||||
before stop.
|
||||
Ref/unref can be used to add or remove a reference count on the event
|
||||
loop: Every watcher keeps one reference, and as long as the reference
|
||||
count is nonzero, C<ev_loop> will not return on its own. If you have
|
||||
a watcher you never unregister that should not keep C<ev_loop> from
|
||||
returning, ev_unref() after starting, and ev_ref() before stopping it. For
|
||||
example, libev itself uses this for its internal signal pipe: It is not
|
||||
visible to the libev user and should not keep C<ev_loop> from exiting if
|
||||
no event watchers registered by it are active. It is also an excellent
|
||||
way to do this for generic recurring timers or from within third-party
|
||||
libraries. Just remember to I<unref after start> and I<ref before stop>.
|
||||
|
||||
=back
|
||||
|
||||
|
@ -449,6 +451,14 @@ time, it will still time out after (roughly) and hour. "Roughly" because
|
|||
detecting time jumps is hard, and soem inaccuracies are unavoidable (the
|
||||
monotonic clock option helps a lot here).
|
||||
|
||||
The relative timeouts are calculated relative to the C<ev_now ()>
|
||||
time. This is usually the right thing as this timestamp refers to the time
|
||||
of the event triggering whatever timeout you are modifying/starting. If
|
||||
you suspect event processing to be delayed and you *need* to base the timeout
|
||||
ion the current time, use something like this to adjust for this:
|
||||
|
||||
ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
|
||||
|
||||
=over 4
|
||||
|
||||
=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
|
||||
|
@ -587,7 +597,7 @@ program when the crontabs have changed).
|
|||
|
||||
Signal watchers will trigger an event when the process receives a specific
|
||||
signal one or more times. Even though signals are very asynchronous, libev
|
||||
will try its best to deliver signals synchronously, i.e. as part of the
|
||||
will try it's best to deliver signals synchronously, i.e. as part of the
|
||||
normal event processing, like any other event.
|
||||
|
||||
You cna configure as many watchers as you like per signal. Only when the
|
||||
|
|
Loading…
Reference in New Issue