|
|
|
@ -364,6 +364,21 @@ flag.
|
|
|
|
|
This flag setting cannot be overridden or specified in the C<LIBEV_FLAGS> |
|
|
|
|
environment variable. |
|
|
|
|
|
|
|
|
|
=item C<EVFLAG_NOINOTIFY> |
|
|
|
|
|
|
|
|
|
When this flag is specified, then libev will not attempt to use the |
|
|
|
|
I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and |
|
|
|
|
testing, this flag can be useful to conserve inotify file descriptors, as |
|
|
|
|
otherwise each loop using C<ev_stat> watchers consumes one inotify handle. |
|
|
|
|
|
|
|
|
|
=item C<EVFLAG_NOSIGNALFD> |
|
|
|
|
|
|
|
|
|
When this flag is specified, then libev will not attempt to use the |
|
|
|
|
I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is |
|
|
|
|
probably only useful to work around any bugs in libev. Consequently, this |
|
|
|
|
flag might go away once the signalfd functionality is considered stable, |
|
|
|
|
so it's useful mostly in environment variables and not in program code. |
|
|
|
|
|
|
|
|
|
=item C<EVBACKEND_SELECT> (value 1, portable select backend) |
|
|
|
|
|
|
|
|
|
This is your standard select(2) backend. Not I<completely> standard, as |
|
|
|
@ -520,9 +535,10 @@ It is definitely not recommended to use this flag.
|
|
|
|
|
|
|
|
|
|
=back |
|
|
|
|
|
|
|
|
|
If one or more of these are or'ed into the flags value, then only these |
|
|
|
|
backends will be tried (in the reverse order as listed here). If none are |
|
|
|
|
specified, all backends in C<ev_recommended_backends ()> will be tried. |
|
|
|
|
If one or more of the backend flags are or'ed into the flags value, |
|
|
|
|
then only these backends will be tried (in the reverse order as listed |
|
|
|
|
here). If none are specified, all backends in C<ev_recommended_backends |
|
|
|
|
()> will be tried. |
|
|
|
|
|
|
|
|
|
Example: This is the most typical usage. |
|
|
|
|
|
|
|
|
@ -2078,17 +2094,20 @@ signal one or more times. Even though signals are very asynchronous, libev
|
|
|
|
|
will try it's best to deliver signals synchronously, i.e. as part of the |
|
|
|
|
normal event processing, like any other event. |
|
|
|
|
|
|
|
|
|
Note that only the default loop supports registering signal watchers |
|
|
|
|
currently. |
|
|
|
|
If you want signals to be delivered truly asynchronously, just use |
|
|
|
|
C<sigaction> as you would do without libev and forget about sharing |
|
|
|
|
the signal. You can even use C<ev_async> from a signal handler to |
|
|
|
|
synchronously wake up an event loop. |
|
|
|
|
|
|
|
|
|
If you want signals asynchronously, just use C<sigaction> as you would |
|
|
|
|
do without libev and forget about sharing the signal. You can even use |
|
|
|
|
C<ev_async> from a signal handler to synchronously wake up an event loop. |
|
|
|
|
You can configure as many watchers as you like for the same signal, but |
|
|
|
|
only within the same loop, i.e. you can watch for C<SIGINT> in your |
|
|
|
|
default loop and for C<SIGIO> in another loop, but you cannot watch for |
|
|
|
|
C<SIGINT> in both the default loop and another loop at the same time. At |
|
|
|
|
the moment, C<SIGCHLD> is permanently tied to the default loop. |
|
|
|
|
|
|
|
|
|
You can configure as many watchers as you like per signal. Only when the |
|
|
|
|
first watcher gets started will libev actually register something with |
|
|
|
|
the kernel (thus it coexists with your own signal handlers as long as you |
|
|
|
|
don't register any with libev for the same signal). |
|
|
|
|
When the first watcher gets started will libev actually register something |
|
|
|
|
with the kernel (thus it coexists with your own signal handlers as long as |
|
|
|
|
you don't register any with libev for the same signal). |
|
|
|
|
|
|
|
|
|
Both the signal mask state (C<sigprocmask>) and the signal handler state |
|
|
|
|
(C<sigaction>) are unspecified after starting a signal watcher (and after |
|
|
|
@ -3801,6 +3820,15 @@ provide a bare-bones event library. See C<ev.h> for details on what parts
|
|
|
|
|
of the API are still available, and do not complain if this subset changes |
|
|
|
|
over time. |
|
|
|
|
|
|
|
|
|
=item EV_NSIG |
|
|
|
|
|
|
|
|
|
The highest supported signal number, +1 (or, the number of |
|
|
|
|
signals): Normally, libev tries to deduce the maximum number of signals |
|
|
|
|
automatically, but sometimes this fails, in which case it can be |
|
|
|
|
specified. Also, using a lower number than detected (C<32> should be |
|
|
|
|
good for about any system in existance) can save some memory, as libev |
|
|
|
|
statically allocates some 12-24 bytes per signal number. |
|
|
|
|
|
|
|
|
|
=item EV_PID_HASHSIZE |
|
|
|
|
|
|
|
|
|
C<ev_child> watchers use a small hash table to distribute workload by |
|
|
|
|