|
|
|
@ -28,14 +28,14 @@ kqueue mechanisms for file descriptor events, relative timers, absolute |
|
|
|
timers with customised rescheduling, signal events, process status change |
|
|
|
events (related to SIGCHLD), and event watchers dealing with the event |
|
|
|
loop mechanism itself (idle, prepare and check watchers). It also is quite |
|
|
|
fast (see a L<http://libev.schmorp.de/bench.html|benchmark> comparing it |
|
|
|
to libevent). |
|
|
|
fast (see this L<benchmark|http://libev.schmorp.de/bench.html> comparing |
|
|
|
it to libevent for example). |
|
|
|
|
|
|
|
=head1 CONVENTIONS |
|
|
|
|
|
|
|
Libev is very configurable. In this manual the default configuration |
|
|
|
will be described, which supports multiple event loops. For more info |
|
|
|
about various configuraiton options please have a look at the file |
|
|
|
about various configuration options please have a look at the file |
|
|
|
F<README.embed> in the libev distribution. If libev was configured without |
|
|
|
support for multiple event loops, then all functions taking an initial |
|
|
|
argument of name C<loop> (which is always of type C<struct ev_loop *>) |
|
|
|
@ -73,10 +73,10 @@ not a problem. |
|
|
|
=item ev_set_allocator (void *(*cb)(void *ptr, long size)) |
|
|
|
|
|
|
|
Sets the allocation function to use (the prototype is similar to the |
|
|
|
realloc function). It is used to allocate and free memory (no surprises |
|
|
|
here). If it returns zero when memory needs to be allocated, the library |
|
|
|
might abort or take some potentially destructive action. The default is |
|
|
|
your system realloc function. |
|
|
|
realloc C function, the semantics are identical). It is used to allocate |
|
|
|
and free memory (no surprises here). If it returns zero when memory |
|
|
|
needs to be allocated, the library might abort or take some potentially |
|
|
|
destructive action. The default is your system realloc function. |
|
|
|
|
|
|
|
You could override this function in high-availability programs to, say, |
|
|
|
free some memory if it cannot allocate memory, to use a special allocator, |
|
|
|
@ -88,7 +88,7 @@ Set the callback function to call on a retryable syscall error (such |
|
|
|
as failed select, poll, epoll_wait). The message is a printable string |
|
|
|
indicating the system call or subsystem causing the problem. If this |
|
|
|
callback is set, then libev will expect it to remedy the sitution, no |
|
|
|
matter what, when it returns. That is, libev will geenrally retry the |
|
|
|
matter what, when it returns. That is, libev will generally retry the |
|
|
|
requested operation, or, if the condition doesn't go away, do bad stuff |
|
|
|
(such as abort). |
|
|
|
|
|
|
|
@ -102,9 +102,10 @@ events, and dynamically created loops which do not. |
|
|
|
|
|
|
|
If you use threads, a common model is to run the default event loop |
|
|
|
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 lockign |
|
|
|
whatsoever, so if you mix calls to different event loops, make sure you |
|
|
|
lock (this is usually a bad idea, though, even if done right). |
|
|
|
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). |
|
|
|
|
|
|
|
=over 4 |
|
|
|
|
|
|
|
@ -119,7 +120,7 @@ If you don't know what event loop to use, use the one returned from this |
|
|
|
function. |
|
|
|
|
|
|
|
The flags argument can be used to specify special behaviour or specific |
|
|
|
backends to use, and is usually specified as 0 (or EVFLAG_AUTO) |
|
|
|
backends to use, and is usually specified as 0 (or EVFLAG_AUTO). |
|
|
|
|
|
|
|
It supports the following flags: |
|
|
|
|
|
|
|
@ -132,11 +133,12 @@ thing, believe me). |
|
|
|
|
|
|
|
=item EVFLAG_NOENV |
|
|
|
|
|
|
|
If this flag bit is ored into the flag value then libev will I<not> look |
|
|
|
at the environment variable C<LIBEV_FLAGS>. Otherwise (the default), this |
|
|
|
environment variable will override the flags completely. This is useful |
|
|
|
to try out specific backends to tets their performance, or to work around |
|
|
|
bugs. |
|
|
|
If this flag bit is ored into the flag value (or the program runs setuid |
|
|
|
or setgid) then libev will I<not> look at the environment variable |
|
|
|
C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will |
|
|
|
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 |
|
|
|
|
|
|
|
@ -410,6 +412,20 @@ level-triggering because you keep receiving events as long as the |
|
|
|
condition persists. Remember you cna stop the watcher if you don't want to |
|
|
|
act on the event and neither want to receive future events). |
|
|
|
|
|
|
|
In general you can register as many read and/or write event watchers oer |
|
|
|
fd as you want (as long as you don't confuse yourself). Setting all file |
|
|
|
descriptors to non-blocking mode is also usually a good idea (but not |
|
|
|
required if you know what you are doing). |
|
|
|
|
|
|
|
You have to be careful with dup'ed file descriptors, though. Some backends |
|
|
|
(the linux epoll backend is a notable example) cannot handle dup'ed file |
|
|
|
descriptors correctly if you register interest in two or more fds pointing |
|
|
|
to the same file/socket etc. description. |
|
|
|
|
|
|
|
If you must do this, then force the use of a known-to-be-good backend |
|
|
|
(at the time of this writing, this includes only EVMETHOD_SELECT and |
|
|
|
EVMETHOD_POLL). |
|
|
|
|
|
|
|
=over 4 |
|
|
|
|
|
|
|
=item ev_io_init (ev_io *, callback, int fd, int events) |
|
|
|
|
Marc Alexander Lehmann
14 years ago