X-Git-Url: https://git.llucax.com/software/libev.git/blobdiff_plain/4dc30d27d0b48de023a3e1e7fd67ac52273580d1..73ce65a9122dd90fac253802fe20630572fdd4be:/ev.html diff --git a/ev.html b/ev.html index f8e5829..8c61bc2 100644 --- a/ev.html +++ b/ev.html @@ -6,7 +6,7 @@ - +
@@ -23,7 +23,8 @@ev_child
- wait for pid status changesev_idle
- when you've got nothing better to doev_prepare
and ev_check
- customise your event loopev_embed
- when one backend isn't enoughReturns the set of backends that are embeddable in other event loops. This
+is the theoretical, all-platform, value. To find which backends
+might be supported on the current system, you would need to look at
+ev_embeddable_backends () & ev_supported_backends ()
, likewise for
+recommended ones.
See the description of ev_embed
watchers for more info.
Sets the allocation function to use (the prototype is similar to the @@ -355,8 +366,12 @@ 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 cannot rely on this :).
+etc.). None of the active event watchers will be stopped in the normal +sense, so e.g.ev_is_active
might still return true. It is your
+responsibility to either stop all watchers cleanly yoursef before
+calling this function, or cope with the fact afterwards (which is usually
+the easiest thing, youc na just ignore the watchers and/or free ()
them
+for example).
ev_<type>_start (loop, watch
corresponding stop function (ev_<type>_stop (loop, watcher *)
.
As long as your watcher is active (has been started but not stopped) you
must not touch the values stored in it. Most specifically you must never
-reinitialise it or call its set macro.
-You can check whether an event is active by calling the ev_is_active
-(watcher *)
macro. To see whether an event is outstanding (but the
-callback for it has not been called yet) you can use the ev_is_pending
-(watcher *)
macro.
+reinitialise it or call its set
macro.
Each and every callback receives the event loop pointer as first, the
registered watcher structure as second, and a bitset of received events as
third argument.
@@ -591,6 +602,84 @@ programs, though, so beware.
In the following description, TYPE
stands for the watcher type,
+e.g. timer
for ev_timer
watchers and io
for ev_io
watchers.
ev_init
(ev_TYPE *watcher, callback)This macro initialises the generic portion of a watcher. The contents
+of the watcher object can be arbitrary (so malloc
will do). Only
+the generic parts of the watcher are initialised, you need to call
+the type-specific ev_TYPE_set
macro afterwards to initialise the
+type-specific parts. For each type there is also a ev_TYPE_init
macro
+which rolls both calls into one.
You can reinitialise a watcher at any time as long as it has been stopped +(or never started) and there are no pending events outstanding.
+The callbakc is always of type void (*)(ev_loop *loop, ev_TYPE *watcher,
+int revents)
.
ev_TYPE_set
(ev_TYPE *, [args])This macro initialises the type-specific parts of a watcher. You need to
+call ev_init
at least once before you call this macro, but you can
+call ev_TYPE_set
any number of times. You must not, however, call this
+macro on a watcher that is active (it can be pending, however, which is a
+difference to the ev_init
macro).
Although some watcher types do not have type-specific arguments
+(e.g. ev_prepare
) you still need to call its set
macro.
ev_TYPE_init
(ev_TYPE *watcher, callback, [args])This convinience macro rolls both ev_init
and ev_TYPE_set
macro
+calls into a single call. This is the most convinient method to initialise
+a watcher. The same limitations apply, of course.
ev_TYPE_start
(loop *, ev_TYPE *watcher)Starts (activates) the given watcher. Only active watchers will receive +events. If the watcher is already active nothing will happen.
+ev_TYPE_stop
(loop *, ev_TYPE *watcher)Stops the given watcher again (if active) and clears the pending
+status. It is possible that stopped watchers are pending (for example,
+non-repeating timers are being stopped when they become pending), but
+ev_TYPE_stop
ensures that the watcher is neither active nor pending. If
+you want to free or reuse the memory used by the watcher it is therefore a
+good idea to always call its ev_TYPE_stop
function.
Returns a true value iff the watcher is active (i.e. it has been started +and not yet been stopped). As long as a watcher is active you must not modify +it.
+Returns a true value iff the watcher is pending, (i.e. it has outstanding
+events but its callback has not yet been invoked). As long as a watcher
+is pending (but not active) you must not call an init function on it (but
+ev_TYPE_set
is safe) and you must make sure the watcher is available to
+libev (e.g. you cnanot free ()
it).
Returns the callback currently set on the watcher.
+Change the callback. You can change the callback at virtually any time +(modulo threads).
+Unlike ev_timer
's, they are not based on real time (or relative time)
but on wallclock time (absolute time). You can tell a periodic watcher
to trigger "at" some specific point in time. For example, if you tell a
-periodic watcher to trigger in 10 seconds (by specifiying e.g. c<ev_now ()
-+ 10.>) and then reset your system clock to the last year, then it will
+periodic watcher to trigger in 10 seconds (by specifiying e.g. ev_now ()
++ 10.
) and then reset your system clock to the last year, then it will
take a year to trigger the event (unlike an ev_timer
, which would trigger
roughly 10 seconds later and of course not if you reset your system time
again).
SIGxxx
constants).
+
+
+
+
ev_child
- wait for pid status changesPrepare and check watchers are usually (but not always) used in tandem: prepare watchers get invoked before the process blocks and check watchers afterwards.
-Their main purpose is to integrate other event mechanisms into libev. This -could be used, for example, to track variable changes, implement your own -watchers, integrate net-snmp or a coroutine library and lots more.
+Their main purpose is to integrate other event mechanisms into libev and +their use is somewhat advanced. This could be used, for example, to track +variable changes, implement your own watchers, integrate net-snmp or a +coroutine library and lots more.
This is done by examining in each prepare call which file descriptors need
to be watched by the other library, registering ev_io
watchers for
them and starting an ev_timer
watcher for any timeouts (many libraries
@@ -1049,6 +1143,91 @@ macros, but using them is utterly, utterly and completely pointless.
ev_embed
- when one backend isn't enoughThis is a rather advanced watcher type that lets you embed one event loop
+into another (currently only ev_io
events are supported in the embedded
+loop, other types of watchers might be handled in a delayed or incorrect
+fashion and must not be used).
There are primarily two reasons you would want that: work around bugs and +prioritise I/O.
+As an example for a bug workaround, the kqueue backend might only support +sockets on some platform, so it is unusable as generic backend, but you +still want to make use of it because you have many sockets and it scales +so nicely. In this case, you would create a kqueue-based loop and embed it +into your default loop (which might use e.g. poll). Overall operation will +be a bit slower because first libev has to poll and then call kevent, but +at least you can use both at what they are best.
+As for prioritising I/O: rarely you have the case where some fds have +to be watched and handled very quickly (with low latency), and even +priorities and idle watchers might have too much overhead. In this case +you would put all the high priority stuff in one loop and all the rest in +a second one, and embed the second one in the first.
+As long as the watcher is active, the callback will be invoked every time
+there might be events pending in the embedded loop. The callback must then
+call ev_embed_sweep (mainloop, watcher)
to make a single sweep and invoke
+their callbacks (you could also start an idle watcher to give the embedded
+loop strictly lower priority for example). You can also set the callback
+to 0
, in which case the embed watcher will automatically execute the
+embedded loop sweep.
As long as the watcher is started it will automatically handle events. The
+callback will be invoked whenever some events have been handled. You can
+set the callback to 0
to avoid having to specify one if you are not
+interested in that.
Also, there have not currently been made special provisions for forking:
+when you fork, you not only have to call ev_loop_fork
on both loops,
+but you will also have to stop and restart any ev_embed
watchers
+yourself.
Unfortunately, not all backends are embeddable, only the ones returned by
+ev_embeddable_backends
are, which, unfortunately, does not include any
+portable one.
So when you want to use this feature you will always have to be prepared +that you cannot get an embeddable loop. The recommended way to get around +this is to have a separate variables for your embeddable loop, try to +create it, and if that fails, use the normal loop for everything:
+struct ev_loop *loop_hi = ev_default_init (0); + struct ev_loop *loop_lo = 0; + struct ev_embed embed; + + // see if there is a chance of getting one that works + // (remember that a flags value of 0 means autodetection) + loop_lo = ev_embeddable_backends () & ev_recommended_backends () + ? ev_loop_new (ev_embeddable_backends () & ev_recommended_backends ()) + : 0; + + // if we got one, then embed it, otherwise default to loop_hi + if (loop_lo) + { + ev_embed_init (&embed, 0, loop_lo); + ev_embed_start (loop_hi, &embed); + } + else + loop_lo = loop_hi; + ++
Configures the watcher to embed the given loop, which must be
+embeddable. If the callback is 0
, then ev_embed_sweep
will be
+invoked automatically, otherwise it is the responsibility of the callback
+to invoke it (it will continue to be called until the sweep has been done,
+if you do not want thta, you need to temporarily stop the embed watcher).
Make a single, non-blocking sweep over the embedded loop. This works
+similarly to ev_loop (embedded_loop, EVLOOP_NONBLOCK)
, but in the most
+apropriate way for embedded loops.
ev_once
:
- Feeds the given event set into the event loop, as if the specified event had happened for the specified watcher (which must be a pointer to an initialised but not necessarily started event watcher).
Feed an event on the given fd, as if a file descriptor backend detected the given events it.
Feed an event as if the given signal occured (loop must be the default loop!).
+Feed an event as if the given signal occured (loop
must be the default
+loop!).
TBD.
+Libev comes with some simplistic wrapper classes for C++ that mainly allow +you to use some convinience methods to start/stop watchers and also change +the callback model to a model using method callbacks on objects.
+To use it,
+#include <ev++.h> + ++
(it is not installed by default). This automatically includes ev.h
+and puts all of its definitions (many of them macros) into the global
+namespace. All C++ specific things are put into the ev
namespace.
It should support all the same embedding options as ev.h, most notably
+EV_MULTIPLICITY
.
Here is a list of things available in the ev
namespace:
ev::READ
, ev::WRITE
etc.These are just enum values with the same values as the EV_READ
etc.
+macros from ev.h.
ev::tstamp
, ev::now
Aliases to the same types/functions as with the ev_
prefix.
ev::io
, ev::timer
, ev::periodic
, ev::idle
, ev::sig
etc.For each ev_TYPE
watcher in ev.h there is a corresponding class of
+the same name in the ev
namespace, with the exception of ev_signal
+which is called ev::sig
to avoid clashes with the signal
macro
+defines by many implementations.
All of those classes have these methods:
++
The constructor takes a pointer to an object and a method pointer to
+the event handler callback to call in this class. The constructor calls
+ev_init
for you, which means you have to call the set
method
+before starting it. If you do not specify a loop then the constructor
+automatically associates the default loop with this watcher.
The destructor automatically stops the watcher if it is active.
+Associates a different struct ev_loop
with this watcher. You can only
+do this when the watcher is inactive (and not pending either).
Basically the same as ev_TYPE_set
, with the same args. Must be
+called at least once. Unlike the C counterpart, an active watcher gets
+automatically stopped and restarted.
Starts the watcher. Note that there is no loop
argument as the
+constructor already takes the loop.
Stops the watcher if it is active. Again, no loop
argument.
ev::timer
, ev::periodic
onlyFor ev::timer
and ev::periodic
, this invokes the corresponding
+ev_TYPE_again
function.
ev::embed
onlyInvokes ev_embed_sweep
.
Example: Define a class with an IO and idle watcher, start one of them in +the constructor.
+class myclass + { + ev_io io; void io_cb (ev::io &w, int revents); + ev_idle idle void idle_cb (ev::idle &w, int revents); + + myclass (); + } + + myclass::myclass (int fd) + : io (this, &myclass::io_cb), + idle (this, &myclass::idle_cb) + { + io.start (fd, ev::READ); + } + +