|
|
|
@ -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 |
|
|
|
|