mirror of /home/gitosis/repositories/libev.git
*** empty log message ***
This commit is contained in:
parent
df2c47ff45
commit
9da4c3cb1d
3
Changes
3
Changes
|
@ -1,10 +1,7 @@
|
|||
Revision history for libev, a high-performance and full-featured event loop.
|
||||
|
||||
TODO: ev_walk
|
||||
TODO: signal handling per loop
|
||||
TODO: NSIG etc.
|
||||
TODO: NOSIGFD/NOEVTFD/NOINOTIFY?
|
||||
TODO: gotsig per-loop
|
||||
- incompatible change: do not necessarily reset signal handler
|
||||
to SIG_DFL when a sighandler is stopped.
|
||||
- ev_default_destroy did not properly free or zero some members,
|
||||
|
|
52
ev.pod
52
ev.pod
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue